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ON THE FRONT LINE OF GAME INNOVATION 



PLAN 




Can Subsidized Hardware 
Save PC Gaming? 



With one of the largest 
console launches ever 
just behind us and at 
least two more loom- 
ing on the horizon over the next 18 
months, many people are speculating 
about the features of these next sys- 
tems. Upon seeing the impressive fea- 
ture sets of the new consoles, some 
have raised questions as to the long- 
term vi abi I i ty of th e PC as a gam i n g 
platform. It's tough to look at a console 
spec sheet, read that it has broadband 
Internet access, amazing graphics and 
audio capabilities, a keyboard, DVD 
support, support for electronic software 
distribution and backwards compatibil- 
ity, and not see that the PC faces stiff 
competition. The traditional strengths 
of the PC are being co-opted by con- 
soles. I for one don't believe PC gaming 
will go away, but the platform must 
confront these challenges head-on. 

To grow the PC market, prices must 
continue to drop. Fortunately they are, 
and it's one reason I'm bullish on the 
PC's future. One big reason for recent 
drops in PC prices is the direct result of 
marketing campaigns by ISPs like 
Compuserve and AOL. Compuserve, for 
example, is subsidizing the cost of 
Compaq, HP and eMachine entry-level 
systems to the tune of a $400 rebate at 
purchase. In return, these consumers 
(many of them first-time PC purchasers) 
agree to subscribe to Compuserve for 
three years at $21.95 per month. These 
I SPs are gambi i ng that it's better to 
underwrite the cost of these new 
machines today and recoup that invest- 
ment through extended onlineservice 
agreements. The ISP gets reimbursed for 
its up-front investment from these 
multi-year service agreements, it gets 
"content" in the form of new chat par- 
ticipants, more eyeballs for which it can 
sell advertising space on its service, and 
other assorted benefits. If it persuades 
these indentured servants — I mean, 
customers — to stay with Compuserve 
after the agreement is terminated, so 
much the better for the ISP. The bottom 
lineisthat asl write this, you can buy a 
brand new 400MHz eMachine with 15- 
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inch monitor and a color printer for 
about $90 more than a Dreamcast. 

While I'm glad that more PCs are 
working their way into homes — it cer- 
tainly will grow the base of casual 
gamers — there are a couple of aspects 
to these incentives that don't bode well 
for the PC game industry. First, these 
rebate programs are seeding households 
with machines barely equipped to play 
today's games. Th e I atest graph i cs an d 
audio hardware won't be found in a 
$289 computer, and without these capa- 
bilities, the systems offer little in terms 
of a cutti n g-edge gam i n g experi en ce. 
Second, long-term service agreements 
with onlineserviceslikeCompuserve 
could hamper the growth of broadband 
access to the Internet, and enabling 
broadband access is essential for grow- 
ing the on line gaming market. 

It would be interesting to see a major 
game pu bl i sh er I i ke El ectron i c Arts step 
up and subsidizea lineof high-end 
game PCs, targeting veteran PC owners 
and hard-core gamers. In return for the 
rebate at purchase, these consumers 
might agree to buy a certain number of 
games from EA over a span of years (the 
Columbia House music club model), or 
sign a multi-year subscription to a per- 
sistent game world like Ultima Online. 
The latter option is especially intrigu- 
ing, sincetheriskto publishers of these 
games is high — developing and main- 
taining a persistent world is expensive, 
they are more difficult to manage, and 
more rides on their success than with 
traditional games. A publisher could 
ensure that when the game was built, 
some percentage of players would be 
locked into thegame. A guaranteed rev- 
enue stream over a period of years looks 
good on the books, and in thehit-or- 
miss world of game publishing, that's 
important to Wall Street. 

Of course, there's nothing stopping 
any of the console manufacturers from 
launching a similar rebate program to 
entice their customers. It may simply 
be a matter of who strikes first. ■ 
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New Products 
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A New Chip off the Old Block 

METACREATIONS has unveiled Carrara, 
its newest entry into the fray of "bar- 
gain" 3D modeling and animation 
packages. The name is appropriate 
enough: Italy's Carrara marble has 
been prized for its unsurpassed quality 
since ancient times, back when a huge 
slab of marble was the original model- 
ing environment for 3D artists. 

Carrara is actually the marriage of 
MetaCreations' Ray Dream Studio and 
Infini-D products. So what separates it 
from the rest of increasingly crowded 
pack of 3D modeling and animation 
programs? It has much the same laun- 
dry list of features and effects as many 
of its competitors, including multiple 
renderers, Direct3D and OpenGL sup- 
port, importing and exporting of most 
industry-standard 2D and 3D file for- 
mats, scads of shaders and presets, and 
an SDK for customization. However, 
one feature that sets it apart is its clean, 
attractive user interface, which lacks 
the screen -clogging blizzard of buttons 





•si 




Mi 


^ 1 



characteristic of certain wildly popular 
high -end packages. 

Carrara will sell for $499 and run on 
Windows 95/98/2000/NT 4.0 and 
Macintosh platforms. 
■ MetaCreations Corp. 

Carpinteria, Calif. 

(805) 566-6200 

http://www.metacreations.com 

X-File Management and More 

NxN SOFTWARE has announced Alien- 
brain, the successor to its groundbreak- 
ing asset management tool tailored 
specifically for game developers, 
MediaStation. Remember back in high 
school when you wrote your first game? 
M aybe you had a few dozen files and 
kept track of them on the back of your 
physics homework. Whatever system 
you had, it wouldn't work on today's 
development projects which now com- 
prise thousands of files and mountains 
of media to manage. 

The folks at NxN feel your pain, and 
AN en brain is their antidote to the 
mind-boggling complexity of manag- 
ing a game development project. The 
client/server system includes four mod- 
ules to track file management, version 
control, process automation and pro- 
ject tracking across differ- 
ent user groups: "Genius" 
is designed for the artists 
on your team, "Intelli- 
gence" for the program- 
mers, "Control" is the 
command center for pro- 
ject administrators and 
tool developers, and 
"Knowledge" is for pro- 
ducer-types. While the 
nomenclature won't settle 
any debates about who 
the real brains on your 
team are, each module 
CO n tai n s f eat u res an d 
functionality unique to 
the needs of its users. 



New Products: MetaCreations intro- 
duces Carrara, NxN rolls out Alien- 
brain, and Criterion unveils its next 
generation of Renderware. p. 7 

Industry Watch: Dell snubsATi, 
M icrosoft shows off its new console, 
Sony divulges more PSX2 secrets, and 
Aureal busts out with boards, p. 8 



Product Review: Jeff Lander sings the 
praises of multi-resolution meshes as he 
reports on Digi nation's Multi Res Tool kit 
and Plug-in for 3D Studio Max. p. 10 

Al i en brai n 's server systems requ i re 
Windows NT 4.0 or later, and clients 
require Windows 95/98/2000/NT 4.0. 
Pricing was not yet finalized at press 
time, but the servers are expected to 
cost in the neighborhood of $4,900, 
with client systems priced at around 
$1,900. NxN also offers flexible volume 
pricing packages. 

■ NxN Software AG 
Munich, Germany 
+49 (89) 27-32-24-0 
http://www.alienbrain.com 

Gearing Up for the Next Generation 

CRITERION SOFTWARE has revealed the 
third generation of its multi -platform 
3D development toolkit, Renderware. 
By now we've all gotten an idea of 
what the near future of 3D gaming 
holds both for PCs and consoles. As 
demands on developers increase, plat- 
forms diversify and pressure builds to 
decrease development lead time, more 
developers may be considering outside 
resources for help. 

Renderware is based on a streamlined 
plug-in architecture that allows develop- 
ers to mix and match functionality by 
overloading the pipeline with their own 
tools (physics or collision detection, for 
example,) when they so desire. The PC 
version supports Glide, OpenGL and 
Direct3D, with a device-independent 
architecture that will enable easier port- 
ing to consoles and tomorrow's digital 
TV platforms. 

Renderware 3 will be available by 
year's end for PC, Playstation 2 and 
i Mac at $1,000 per programmer per 
platform per year with no royalties, 
and third-party plug-in development is 
in full swing. Linux, Dreamcast and 
Nintendo Dolphin versions of Render- 
ware are also being considered. 

■ Criterion Software Ltd. 
Guildford, Surrey, U.K. 
-1-44 (0) 1483-406200 
http://www.renderware.com 



Carrara's modeling interface: its lacl< of clutter may 
be inviting to some, limiting to ottiers. 
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Industry Watch 



DREAMS DO COME TRUE. Sega's Dream 
cast launch proved to be better than 
the company hoped, with preliminary 
figures indicating that $97 million in 
sales were rung up around the U.S. on 
9/9/99. Sega claims it was the biggest 
24 hours in entertainment retail sales, 
easily surpassing the $28 million that 
The Phantom Menace took in on open- 
ing day last May. 

PSX2 NEWS. Carefully timed to coin- 
cide with the Dreamcast launch, Sony 
stole some of Sega's thunder with a 
number of Playstation 2 announce- 
ments. The company revealed that the 
PSX2 will debut in Japan next March 
(three months later than originally 
planned, possibly due to chip manufac- 
turing problems), and in the U.S. and 
Europe next fall. Japanese consumers 
will have to cough up 39,800 yen ($365 
at press time) for the system. Sony also 
revealed that it will distribute games via 
the Internet, made possible by the 
PSX2's broadband support and an 
upcoming hard drive Sony will sell. To 
support this new means of distributing 
console titles, Sony is creating an elec- 
tronic transaction system, and an e- 
distribution server. In developer news, 
Sony will give PSX 2 developers tools 
that support the regular Playstation 
programming/debugging mode as well 
as a new workstation mode for creating 
PSX 2 graphics, all on the same system. 

ENTER MICROSOFT... At ECTS, M icro 
soft demo'd its upcoming console 
(code-named the "X-Box") to various 
developers and analysts. As we go to 
press, no release date for this console 




has been hinted at, and product specs 
are sketchy. But the word on the street 
is that theX-Box will be based around 
a 500MHz Intel chip, the Nvidia 
GeForce 256, a DVD drive, a multi-giga- 
byte hard disk, and of course, some fla- 
vor of Windows. Who will produce this 
console? Not M icrosoft, apparently — 
Dell, Gateway and Samsung have been 
lined up as manufacturers. 

IT'S TEN NO MORE. Total Entertainment 
Network (TEN) ditched its name and its 
target market, deciding that the casual 
game market is more lucrative than its 
previous focus on hard-core players. The 
company, now called Pogo.com, is 
focused strictly on card, trivia, board 
and other "family" games. The site has 
more than 3.5 million members, and 
has lined up has distribution relation- 
ships with (oHome, Alta Vista, Cnet, 
Excite, Go, Netscape, and Sony. 

BE LINES UP TITLES. Be Inc. and Mono- 
lith announced that Shogo: Mobile 
Armor Division will be brought to the 
BeOS. Shogo will be developed and pub- 
lished for BeOS by Wildcard Design. At 
ECTS, Be showed Civilization: Call to 
Power, Corum 3, and Quake 2 running 
on its operating system. 

DELL DECISION HURTS ATI. ATI 

acknowledged that Dell's recent deci- 
sion go with Nvidia chips in its 
OptiPlex computer line will cost ATI 
$10 million in sales per quarter. The 
company still expects to meet fourth- 
quarter sales projections when it 
reports results on October 21, but that 
didn't quell some panicked investors, 
and trading of ATI's stock was halted 
on both the Toronto and Nasdaq 
exchanges after the company revealed 
the cost of that lost deal. ATI points 
out that it will still supply Dell's note- 
book PCs, and that its relation- 
ship with the big computer 
company is still strong. 

AUREAL LAUNCHES CARDS. 

Aureal entered the board busi- 
ness and is shipping two new 
Aureal -branded sound cards, 
the Vortex SQ1500 and the 
Vortex2 SQ2500. The new 
cards are marketed under the 
Aureal name by I/O Magic 
Corporation, and are support- 
ed by a multimillion dollar 



marketing campaign. Based on 
Au real's AU8810 processor, the 
SQ1500 supports A3D 1.0 and features 
a 512-voice wavetable synthesizer. The 
SQ2500 is based on a new version of 
the Vortex2 AU8830 processor and 
supports A3D 2.0 with a 576-voice 
wavetable synthesizer. ■ 



UPCOMING EVENTS 

CALENDAR 



1999 GDC RoadTrips 

OGDEN ECCLES CONFERENCE 
CENTER 

Salt Lake City, Utah 
November 1, 1999 

THOMPSON CONFERENCE CENTER 
AT THE UNIVERSITY OF TEXAS 

Austin, Tex. 

November 3, 1999 

Cost: $120 ea. (discounts available) 
http://roadtrips.gdconf.com 

Software Development East 

WASHINGTON CONVENTION CENTER 
Washington, D.C. 
November 8-12, 1999 
Cost: variable 
http://www.sdexpo.com 

RE:Play Real World Conference 

TISCHMAN AUDITORIUM ATTHE 
PARSONS SCHOOL OF DESIGN 

New York, N.Y. 

November 13, 1999 

Cost: free 

h tt p :// www. ey ebeam . o rg/ rep I ay 

Comdex Fall 

SANDS EXPO & CONVENTION CENTER 
Las Vegas, Nev. 
November 15-19, 1999 
Cost: variable 
http://www.comdex.com 



Sony took advantage of the Dreamcast launch 
to divulge more tidbits about the Playstation 2. 
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Digimation's 
MuhiRes 



bif Jeff LaMcler 



Scalable 3D graphics has been a 
major event in 3D graphics this 
past year. With so many differ- 
ent gaming platforms and such a variety 
of graphics cards, making content that 
performs similarly on all systems is a 
real challenge. Game developers have 
commonly used different level-of-detail 
models to balance the performance. 
However, creating LOD models is a time 
consuming and tedious project for any 
game artist. Furthermore, dynamically 
changing between LOD models during 
the game can lead to annoying popping 
as they switch. Graphics researchers 
have been promoting the idea of con- 
tinuous LOD algorithms for 3D models. 
In these algorithms, the model will 
smoothly scale from very high to very 
low polygon counts. In fact, Stan Mel ax 
wrote an article in this magazine about 
implementing a continuous LOD sys- 
tem ("A Simple, Fast, and Effective 
Polygon Reduction Algorithm," Novem- 
ber 1998). However, creating a system 
that handles all the lighting and texture 
information and smoothly integrates 
into your production is a task that 
could easily tie up development 
resources for sometime. 



I DON'T HAVETHAT KIND OF TIME. With 
this in mind, I looked with interest at 
several commercially available continu- 
ous LOD systems at Siggraph 1998. 
One of these was a very interesting sys- 
tem developed by Intel. At thetime, 
the project was not quite ready to be a 
product, but looked very promising. 
Well, at the GDC this year, Intel 
unveiled the fruits of this labor. They 
have teamed up with Digimation to 
produce the MultiRes Software Too I kit 
and Plug-in for 3D Studio Max. 

The MultiRes Plug-in enhances 3D 
Studio Max by providing a method for 
reducing a high polygon mesh to a 
lower polygon count mesh. In this way, 
the plug-in is similar to the Optimize 
routine that is built into 3D Studio 
Max. However, MultiRes is quite a bit 
more powerful. For example, you can 
set exact polygon count targets as well 
as a reduction percentage. Also, Multi- 
Res does an excellent job of preserving 
texture coordinates and vertex normals. 
Artists are even able to fine-tune the 
reduction algorithm by a variety of con- 
trols as wel I as sel ecti n g th e verti ces n ot 
to remove. 

Asa modeling tool alone, this pro- 
vides a pretty powerful and useful way 
for artists to craft content. However, the 
real power of M ultiRes is realized by 
creating a multi-resolution mesh. This 
special mesh file contains all theinfor- 




FIGURE 1. The bottom dinosaur's 
face count has been reduced dramati- 
cally, but lool<s fine from a distance. 



jeff Lander is always trying to find a tool to make his life easier and cut down on 
unnecessary work at Darwin 3D. If you can recommend any nifty tools, pass them 
on tojeffl@darwin3d.com. 



mation needed to create a mesh that 
can dynamically scale from its full reso- 
lution down to 1 polygon composed of 
3 vertices. This MultiRes mesh can then 
be used directly in your game as scal- 
able content. It can also be exported 
into the MetaStream 3D format that is 
used with tools from MetaCreations to 
view scalable 3D models on the web. 

You can see an example of MRM in 
action in Figure 1. The first image is the 
original mesh at 6,126 vertices or 
11,766 faces. I then reduced this down 
to just 64 vertices for 120 faces. Obvi- 
ously, this looks pretty bad up close, but 
when the object gets far away it looks 
fine. The M RM algorithm preserved the 
outline of the arms and legs. This is 
where real-time use of M ultiRes really 
makes a difference. A herd of these ani- 
mals at full resolution would grind any 
system to a halt. But a herd of them at 
120 polygons is perfectly reasonable. 
HOW DO I USE IT? If you are a 3D Studio 
Max user, the plug-in couldn't beany 
easier. You simply select your model 
and select the plug-in from the Modifi- 
er panel. You can then "Generate" the 
MultiRes mesh and start interactively 
reducing the vertex count in the 
model. The default generation options 
do a good job of mesh reduction for 
many models. However, you can really 
fine-tune the operation. 

The "Vertex Merging" option allows 
you to determine whether or not 
unconnected areas of the mesh will be 
merged as the reduction proceeds. You 
specify the maximum distance in 3DS 
Max units that the algorithm will con- 
sider for merging. This can be useful if 
your mesh is composed of parts that 
are not topologically connected. 

"Boundary Metric" gives you the 
options with respect to any material 
changes in to model. It will then try to 
avoid collapsing vertices that cross 
these material boundaries. 

Most of thetime, the algorithm 
along with these options will allow 
you to create a good mesh. However, 
there are times that you will want to 
select vertices that you do not want to 
collapse in the model. Perhaps there is 
a feature in the model that is distinct 
and you wish to be preserved. You can 
select the "Maintain Base Vertices" 
option and then select the vertices you 
wish to preserve. These vertices will 
then be maintained throughout the 
reduction process. 
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Thefinal option determines how the 
normals in the model will be handled. 
While vertices are removed, the topolo- 
gy can change pretty dramatically. You 
can simply use the original vertex nor- 
mals throughout the reduction. Other- 
wise, by setting the "Multiple Normals 
per vertex" option, the system will cre- 
ate new normals based on the surround- 
ing faces as the model reduces. This 
option comes at the cost of increasing 
the number of update records that must 
be recorded. Whether or not this is 
needed depends greatly on your applica- 
tion and models. 

That's all there is to it. Once you are 
happy with the reduction, you can save 
it out, ready to use in your application. 
BUT I DON'T USE MAX. If you don't use 
3D Studio Max, you won't get the bene- 
fit of this nifty plug-in. However, the 
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benefits of Multi Res are still available to 
you. The Multi Res Software tool kit con- 
tains all the functions you will need to 
create a scalable mesh. You simply set 
the parameters for the reduction and 
submit a structure containing all the 
vertices, normals, and faces in the 
model to theGenerateMRM function. 

I found it very easy to take models 
created in Softimage and convert them 
intoaMRM by modifying the Digima- 
tion sample viewer. This would be easy 
to do for any polygonal model. 
SO HOW DO I USE IT IN MY GAME? Now I 
have a nice M RM all ready to go and I 
want to use it in my game application. 
The examples provided with the 
Software Too I kit make this easy. There 
is both a DirectBD and OpenGL exam- 
ple of working with a Multi Res mesh. 

One thing developers will appreciate 
is that while the M RM generation func- 
tions are in a Dynamic Link Library 
(DLL), all the run-time code needed to 
display and manipulate the meshes are 
straight C. You need no extra libraries 
to ship with your project. This also 
makes it possible to usetheMRM tech- 
nology on game consoles. 

Also, as the algorithm works by 
changing the connectivity of the 
meshes, the actual vertices are left 
alone. This means that the Multi Res 
algorithm can work with most anima- 
tion schemes such as skeletal deforma- 
tion, morphing, or even QuAKE-style 
mesh flipping. 

OTHER FEATURES. The M uiti Res Tool kit 
also offers another very valuable feature. 
In order to render polygonal meshes in 
the fastest way possible, many 3D 
graphics cards prefer to receive the 
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mesh es as tri an gl e stri ps. Th ese stri ps 
can be tricky to create and often require 
custom tools to generate them. 

M ultiRes provides a way to generate 
tri angle strips from a polygonal model. 
However, si nee the model's topology 
changes, as the level of detail changes 
an initial triangle strip would become 
invalid. To address this issue, the Multi- 
Res Toolkit provides a way to generate 
triangle strips on the fly. Very cool... 
WHATS THE BOTTOM LINE? The 3D S M ax 
MultiRes plug-in is $295. By itself, this 
plug-in may be of use to Max modelers 
who wish to have a better polygon 
reduction tool or want to generate 
MetaStream objects for web viewing. If 
you don't use Max or really want the 
game interactivity, this is probably not 
for you. 

The MultiRes Software Tool kit 
includes three license copies of the Max 
plug-in as well as all the libraries and 
code needed to generate and display 
continuous LOD meshes. The cost of 
the toolkit is a flat fee of $5,995 per fin- 
ished game title. When you consider all 
the technology included and the 
amount of development time it would 
take to create this functionality, this 
seems like a great deal to me. 

Obviously, I'm not the only one who 
thinks this is interesting. Both Valve 
with Team Fortress 2 and Pandemic 
Studios with Dark Reign 2 have licensed 
the Multi Res Tool kit for their upcoming 
3D titles. I expect many more to follow. 

M ultiRes is the first commercial pro- 
ject to come out of the collaboration 
between Intel and Digimation. I cer- 
tainly look forward to other products 
that come of this partnership. ■ 



FIGURE 2. The MultiRes user 
interface. 



Digimation inc. 

St. Rose, La. 
(8oo) 854-4496 
http://www.digimation 
.com 

Price: Plug-in is $295. 
Software toolkit is 
$5,995 per finished 
game, including three 
copies of the plug-in. 

Software Requirements: 

Windows 95/98/2000/ 
NT 4.0; 3D Studio Max 
for the plug-in. 



Pros: 

1. Full source code for plug- 
in and run-time modules 
for Direct 3D and 
OpenGL. 

2. High-quality polygon- 
reduction algorithm with 
great performance. 

3. No per-copy royalties on 
game sales. 



Cons: 

1. Plug-in only comes for 
3D Studio Max. Users of 
other packages must roll 
their own conversion 
programs from library 
included in SDK. 

2. Toolkit cost is up-front 
although pretty reason- 
able. 

3. Users will need to adapt 
their game engines to 
work with the multi- 
resolution meshes. 
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The Blobs Go Marching 
Two by Two 




his may come as a shock to some, but the world is not made up of corridors 
composed of completely planar surfaces. We live in a wildly organic place. 
Hills roll, muscles bulge and fountains splash. The world around you is 
filled with organic shapes which cannot easily be created out of triangles. 



In fact, many of these objects are not 
even just lying around looking all 
organic. They slop, splash, waddle, and 
plop about you all the time. Many 
shapes around you are even in motion. 
These objects change shape effortlessly 
as you game artists crumple under the 
pressure of having to model such phe- 
nomena. When was the last time you 
saw a nice splashing fountain in a 
game, anyway? 

An i mato rs h ave faced th e ch al I en ge 
of vi sual I y creati n g th e organ i c worl d 
we live in for sometime now. To help 
them out, commercial modeling pack- 
ages have provided the artist with tools 
for creating organic shapes. One of the 
methodsfor creating organic objects is 
through the use of blobby balls that 
can be combined together to form a 
clay-like sculpture. The commercial 
animation package developers have 
real i zed th e u sef u I n ess of th i s tech - 
niqueand coined all sorts of propri- 
etary terms for thei r version . You may 
have seen ads for meta-balls, meta-clay, 
blob-modeling, and various other ways 
of combining the term "meta" with 
some form of goop. 

To create an object from this meta- 
goop, an artist drags around primitive 
elements, usually spheres, which repre- 
sent the rough shape of the object. 
Each of these elements has a center 
position and several parameters associ- 
ated with it. These parameters define 
how the element will interact with the 
particles and world surrounding it. You 
can see an example structure for a 
meta-goop particle in Listing 1. 

Theposition describes the center of 
the element. I also need to keep track 
of the radius of i nfluence of the ele- 



ment (actually squared so I save some 
math later) and the strength of the ele- 
ment. This strength parameter defines 
how the element will affect the space 
surrounding it. 

The elements interact with each 
other by creating an energy field 
around them. This is similar to the 
way planets create a gravitational field 
for a solar system. It ispossibleto eval- 
uate the energy of the system at an 
arbitrary point in space. Theformula 
to determinetheamount of energy 
that an element contributes to the 
point is given as: 
distance = squaredDistance(&goop-> 

position ,&test Position) ; 
if (distance < goop->radiusSquared) 
{ 

falloff = l.Of - (distance/goop-> 

radiusSquared); 
fieldStrength += goop->strength * falloff 

* faUoff; 

} 

By running thisformula over all the 
elements in your system, you get the 
exact field strength for that position. 
The energy field creates some interest- 



LISTING 1. A meta-goop particle. 



typedel tMetaGoop 
{ 

tVector position; 
float radiusSquared; 
float strength; 

}; 




ing data but is not much of an object. 
What I want to create are particles that 
will visually grow together as they get 
closer. You can see an example in 
Figure 1. In order to create an object 
that will show this visual aspect of the 
energy field, it is necessary to define a 
value that will represent the outer shell 
of the object — the threshold. 

The energy field varies in strength 
from zero on up at any position you 
may evaluate. In fact, there is nothing 
to keep you from defining negative 
strength for an element, creating nega- 
tive regions, or holes, in the energy 
field. This is useful for effects such as 
denting and the like. To define the sur- 
face of the object in thefield, I can set 
an arbitrary threshold giving the object 
its final shape. 

Thethreshold value defines the 
boundary between the area inside and 




The "meta-goop" seen here produces 
results that are difficult to create with 
traditional modeling techniques. 



W hen not splashing gloop around his kitchen floor, jeff can be found creating real 
timegraphics applications at Darwin 3D. Fling some bits of your own his way at 
jeffl@darwin3d.com. 
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th e area o u tsi de th e sh el I of th e o bj ect . 
Figure 2 shows how an example thresh- 
old value creates a boundary in a 2D 
energy field created by three meta-goop 
entities. 

By adjusting this threshold valuefor 
the energy field, as well as adjusting 
the strength, position, and effective 
radius of individual entities, a great 
variety of objects can be created. But I 
still need to talk about how. 



Walking on Eggshells 

By creating a few meta-goop parti- 
cles and setting some values for 
them, I have created my meta-goop 
system. Run that goop through a func- 
tion that evaluates the energy field, 
apply a surface threshold, and I have 
the surface shel I for the meta-goop 
object defined. But the problem 
remains, how do I draw it? 



I could step across the entire 3D 
space defined by entity radii and eval- 
uate the field. Anywhere the returned 
value is equal to the threshold, I could 
draw a solid cube the size of the steps 
taken. This sounds pretty good. 
Sounds like it would work. Actually, it 
sounds kind of familiar. It sounds 
kind of like volume rendering of vox- 
els for applications such as viewing 
CAT scan data. In fact, that is exactly 
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what I would be doing if I took this 
approach. 

H wever, ren deri n g th e en ergy fi el d 
this way can lead to pretty chunky look- 
ing images unless the step sizeisfairly 
snnall. This is becausethe energy field is 
conti n uous over the enti re range of the 
model world. However, thestepsi took 
walking across the field are in discrete 
steps. If the steps are too big, the image 
can look chunky. This is analogous to 
drawing a lineon a computer graphics 
screen. If the resolution of the screen is 
too low, the line can look very jagged. 
This unfortunate condition is known as 
"thejaggies" and requires some form of 
smooth i n g r an t i al i asi n g to make th e 
lines look better. 

Unfortunately, decreasing the step 
size in my energy field will greatly 
increase the amount of calculations 
that must be made. Therefore, it is nec- 
essary to find a way to smooth out the 
voxel image— sort of antialias the 
meta-surface. 



CAT Scans and Game Development 

Fortunately for me, the graphic 
visualization and medical imaging 
industries have been dealing with this 
issue for quite sometime. Wyvill and 
McPheetersin 1986 and Lorenson and 
Clinein 1987 independently devel- 
oped a system called "marching 
cubes" which enables you to render a 
polygonal approximation of a voxel 
field. One possible unfortunate cir- 
cumstance is that this algorithm may 
be tai n ted by a software patent and I 
am investigating how this will affect 



The Marching Cubes Patent Question 



As many of you who have met 
me and heard me rant on 
the topic know, I believe 
algorithmic software 
patents are totally wrong. I feel they 
completely halt continued development 
down interesting research pathways by 
shrouding a topic with legal pitfalls. 
Graphics researchers create progress by 
building on the work done by others 
before them. I lil<e to imagine the state of 
the industry if Bresenham had patented 
his method for drawing a line on a graph- 
ic display and then charged a licensing 
fee for every line drawn. 

The topic of volume rendering is an 
interesting case in point. As an obvious 
next step in the visualization of volume 
data, it was reported by researchers in 
several publications. However, General 
Electric apparently owns a patent on the 
technique via the Lorenson and Cline 
implementation (U.S. patent 
#4,710,876). As an actual apparatus to 
display medical imaging data, I can 
understand it. However, the patenting of 
a "method for displaying three-dimen- 



sional surface images" seems pretty 
broad to me. 

I have been told by someone via e-mail 
that GE aggressively enforces this patent. 
However, it is not clear to me how this 
would apply to the rendering of an isosur- 
face in a game. Does this mean that any 
modeling program using these tech- 
niques must pay a license to GE? If I cre- 
ate a game using a derivative of marching 
cubes and it is a big hit, am I going to 
receive a stealth patent letter in the mail 
demanding a percentage? How derivative 
does it need to be? The prior art on this 
topic seems limitless, but what can I use 
as a reference and still be safe? 

With the record number of software 
patents being filed, this is going to 
become an increasingly difficult issue for 
game developers in the future. I am 
actively researching the issue and hope 
to report on the results in a later column. 
Anyone with information on the topic, 
please let me l<now. In the meantime, 
always document your research from 
public journals as best you can. Igno- 
rance is not bliss in this situation. 



the issue (see Sidebar). 

That aside, the way marching cubes 
works is pretty simple. Divide the 
region you wish to render into a regu- 
lar 3D grid. Evaluate the energy field at 
each position on this grid. Now, con- 
sider the grid cube by cube. If the ener- 
gy function at all eight corners of the 
cube are less than thethreshold level, 
the entire cube is outside the meta- 



object and the cube can be ignored 
completely. Likewise, if the corners are 
all greater than thethreshold, the cube 
is completely inside the object and can 
also beignored. Theonly cubes that 
need further consideration are those 
that have corners both inside and out- 
si de th e meta-obj ect . Th ese cu bes are 
on the object surface and will be part 
of the final render. 




LISTING 2. Finding the intersection point. 



void FindIntersection( tVector *a, tVector *b, 
float aVal, float bVal, 
float thresh, tVector *result) 

{ 

/// Local Variables 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ^ 
tVector diff; 
float ratio ; 

///////////////////////////////////////////////////////////////////////////////I 
VectorSubtract( a, b, fediff); 
ratio = (thresh - aVal) / (bVal - aVal); 
VectorMultiply( fediff, ratio); 
VectorSubtract(a,&diff, result); 
if (aVal > bVal) 

} 
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GRAPHIC CONTENT 




FIGURE 3 A. One vertex inside and 
the rest outside create one triangle. 



A cube has eight vertices. That 
means that there are 256 possi ble com- 
binations of how a surface can intersect 
with the cube. If you consider symme- 
try, the number of possibilities reduces 
to 14. Much of the literature on surface 
generation using the marching cubes 
routine deals with optimizing for those 
14 special cases. 

However, there is an easier way I 
have seen termed "marching pyramid." 
If you consider a cube of eight vertices 
as being composed of five tetrahedrons 
with four vertices each, the problem is 
greatly simplified. There are now only 
three very simple cases to deal with. 
Th e cases are th e f o 1 1 o wi n g: 

1. One vertex is inside the surface 
and the rest outside. 

2. One vertex outside the surface 
and the rest inside. 

3. Two vertices outside and two 
inside. 

That is all I need to consider. In cases 
land 2, a single triangle is generated. 
In case 3, two triangles are generated. 
You can see the three cases represented 
in Figures 3a-c. 

Once the vertices of the pyramid are 
classified, the actual vertex positions 
of the triangles created are obtained 
by linear interpolation of the corner 
values along each edge. You can see 
thecodefor this in Listing 2. As there 
are five tetrahedrons making up each 
cube, the number of triangles generat- 
ed with the marching pyramid tech- 
nique is greater than what would be 
created from simple marching cubes. 
However, the classification and cre- 
ation step is much simpler and the 
resultant surface is a more accurate 
approximation of the surface. On cur- 




FIGURE 3R. One vertex outside and 
the rest inside also make one triangle. 



rent 3D graphics hardware, the extra 
triangles shouldn't affect performance 
too much. 



Goopy Games 

■ hope it is now clear that these meta- 
goop techniques can be used to cre- 
ate interesting organic objects suitable 
for real-time display. However, there 
are several aspects that actually make 
them ideal for use in games. For one, 
they are procedurally created. Complex 
structures can be generated from sim- 
ple data structures consisting of the 
location and attributes of each particle 
in thesystem. There is no need to store 
a complete mesh. 

In addition, the meta-object can be 
tessellated to different levels depend- 
ing on the initial grid sizeof the voxel 
space. This gives the game a dynamic 
level-of-detail component that is 
needed in these days of varying hard- 
ware performance. 

You can attempt generation of the 
objects in real time through efficient 
optimization of the surface approxima- 
tion routine. You could also simply 
decide to create the objects at load time 
and display them as traditional polygo- 
nal objects during the actual game, or 
evaluate the mesh only when the state 
of thegoop elements changes. This 
kind of flexibility makes for easy inte- 
grati on i n to a vari ety of appi i cati on s. 

I didn't even discuss how the sur- 
faces could be rendered. One obvious 
choice would be to apply environ- 
ment-mapping techniques to create 
the chrome creature from Terminator 2. 
Likewise, you could apply bump-map- 




FIGURE 3 C . Two vertices outside 
and two inside create two tringles. 



ping techniques to bring a water crea- 
ture to life. I think an interesting 
application would be to combine 
meta-surface techniques to a particle 
system liketheonel described last 
summer ("Spray in Your Face," 
Graphic Content, July 1998). 

For more fun, get my demo applica- 
tion off the Game Developer web site 
(http://www.gdmag.com). This will 
allow you to play with the creation of 
meta-goop and start spreading some 
slop around your games. ■ 
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ARTIST'S VIEW 



Mo-Cap and Keyframing, 
Sittin' in a Tree 




san artist, you've heard at one time or another some pretty common 
arguments: photo reference vs. "from memory/' tracing vs. hand- 
drawing, or scanned images vs. hand-painted ones done in Photoshop. 
However, for animators worl<ing on computer games today, there'sa new 



debate when it comes to character ani- 
mation: keyframing vs. motion capture. 

Analogous to the classic Luddite/ 
Promethean struggle that occurs still in 
the scientific community, animators 
tend to divide themselves into two 
camps. On onesideyou have the purists 
who believe mo-cap is the evil product 
of technology run by marketing blow- 
hards. On the other you have the strate- 
gist artist who is constantly looking for 
the better, faster way to get the job 
done. Because in the end if your artwork 
is featured in a computer game and not 
a gallery in New York City, it boils down 
simply to getting thejob done. 

Mo-cap can and will help get thejob 




FIGURE 1. QsA's Orbb marches to 
the beat of a different drummer. 



done faster and better. Like any other 
tool aval I able to the computer artist/ani- 
mator today, it can be used in various 
ways to various degrees. What I'm going 
to do is demonstrate a situation in 
which motion capture and keyframing 
can be married — no, have to be married 
together — to form a solution for one 
i n Stan ce of ch aracter an i mati on . 



Tve Got Ny Eye on You 

eetOrbb. He's cool. He's a charac- 
ter we created for Quake 3: Arena 
(with textures by Kenneth Scott) solely 
fortheweirdnessof making him run 




FIGURE 2. An orthographic view of Orbb'specu 
liar anatomy. 



around on his hands (Figure 1). Because 
of the animation system of the game, 
affording or even showing off any type 
of complex finger animations is impos- 
sible. However, using a little bit of prob- 
lem solving Orbb becomes a great exper- 
iment in evenly combining motion 
capture and keyframed animation. 

I'll explain. Figure 2 shows a more 
orthographic view of our ocular, podi- 
atrically-challenged little friend. In the 
Q3A game engine, each character must 
be divided into three distinct parts: 
head, torso and legs. The parts are tied 
together using a simpletriangletag sys- 
tem (match tab a to tab b). The head 
and torso basically move around when 
you move your mouse 
around (free look) with the 
head motions slightly lead- 
ing those of the torso. The 
legs are purely locomotive 
and couldn't care less what 
the upper body does. Of 
course, death animations are 
all-body inclusive. 

So in Orbb's case his hands 
have essentially become his 
legs, his body casing became 
historso and hiseyeball 
became his head. Setting up 
and attaching him to a biped 
in Character Studio turns out 
looking something like what 
we have in Figure 3. 

Notice that I didn't give 
him arms and that the head 
and torso aren't linked to an 



Still aform of computer game artist concentrate (just add imported beer) nearly 35 yearsin the making, Paul Steed (simply labeled 
"Steed" for easier marketability) will hopefully beapplied to a new project by thetimeyou read this. As usual, product information 
can beattained by dropping a lineto psteed@idsoftwarecom. 
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FIGURE 3. Orbb has been attached 


to a regular biped skeleton. 



underlying skeleton. The reason for this 
is that I intend to apply mo-cap data in 
the form of death animations and loco- 
motive animations mainly to the legs 
(arms), but I'm going to keyframe the 
fingers (toes), body and head anima- 
tions. I won't even concern myself with 
what the unused skeletal parts of the 
biped do at this point since, given 
Orbb's unique anatomy, they don't 
matter (and I can't delete them). 

So, taking a motion-captured run 
cycle I plug it into the character's skele- 
ton (Figure 4). Something doesn't quite 
look right here. If indeed those are sup- 





FIGURE 4 . Orbb's run cycle still needs worl< after plugging in the mo-cap data. 




FIGURE 6 . Adding the mo-cap data to the reversed legs gives better results. 



posed to be arms, the el bows aren't 
quite bending right, now are they? And 
those toes sure don't look likeprehen- 
siledigits. So my dilemma is how to 
make th e I egs act I i ke I egs wh i I e ben d- 
ing likearms. I wonder if I can turn the 
leg around in the up axis? First I'll 
detach the mesh from theskeleton, 
then select the upper thigh and rotate 
i t so th e kn ee faces th e opposi te d i rec- 
tion (Figures). 

Cool. Now we can apply the same 
mo-cap run data to the now-reversed 
legs and see what it looks like (Figure 
6). This looks better. Next we reattach 
the mesh to theskeleton and keyframe 
those fin gers...er, toes, doing some- 
thing cool like pushing off, flicking out 
as they push off, and so on. Doing this 
keyframe work on the hands results in 
poses I ike the ones shown in Figure?. 



In adding keyframes to the fingers I 
try to exaggerate the motions a little. 
J u St as a stage actor wears tons of make- 
up in order to be visiblefrom the back 
row, amplifying animations isjust as 
important in real-time games. Charac- 
ters running around in a game like 
Q3A usually don't appear very large as 
you're trying to stuff rockets down 
their throat from afar. 

So after applying the mo-cap data to 
the arms and keyframing the hands 
and fingers, Orbb runs like he's sup- 
posed to (Figures). I basically get to 
utilize all my animation files such as 
deaths, jumps, backpedals, walks, shuf- 
fles, or whatever, for Orbb's animation 
set as it pertains to his legs and center 
of gravity. I have to make some gross 
adjustments to make sure his weight 
distribution appears correct, but overall 




FIGURE 5. Rotating the legs will 
mal<e them act more lil<e arms. 



FIGURE 7. Keyframing offers us the precision to devise some cool hand poses. 



FIGURE 8 . Mo-cap and l<ey frame data combined to produce our finished run cycle. 
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they workout pretty well. Once the 
locomotive animations are in, I 
keyframe the head and body casing to 
react accordingly. 

This isjust oneof many possiblesitu- 
ationsthat can support both motion 
capture and keyframing. However you 
look at it, mo-cap isjust as useful as 
keyframing if you have a basic under- 
standing of character animation and 
experience with keyframes. Rather than 
turning your nose up at an animation 
aid such as mo-cap, it behooves you at 
least to explore the potential benefit of 
the technology. After all, it's just... 



...A Tool Like Any Other 

Along time ago when I first started 
weight-training, I voiced my frus- 
tration at being so weak. This old bald 
guy from the monastery on base who 
was spotting me said, "Always remem- 
ber. Grasshopper, the weights area 
tool, not a measurement." The same 
applies to the methods and tools we 
use to create character animation with 
the computer. The character animator 
today no more becomes a talentless 
hack because he uses mo-cap than a 
master illustrator shows his inadequa- 
cies because he uses photographic ref- 
erence for his painting. 

I did my first animations back in 
high school when I'd have little stick 
people dancing along the edges of my 
textbooks running, fighting, somer- 
saulting or just plain being lewd. Then 
I got into comic books and began 
telling stories with splash pages and 
sequential story art (panels) a la Kirby, 
Buscema, Byrne, Golden and Miller. 
Comic art or comic strips are the most 
basic example of keyframes. While not 
as literal as flipping a page and watch- 
ing a little stick man come to life, each 
panel in a superhero comic is a static 
representation of a continuing dialog 
and dynamic flow for which your brain 
(instead of thecomputer) provides the 
"tween" frames. 

Learning to draw and portray char- 
acters in this fash ion is perfect basic 
trai n i n g f or ch aracter an i mati on , si n ce 
it forces you to see things in your 
mind clearly enough to put them 
down on paper. This translation of 
thought to media and, more impor- 
tantly, theability to recognize a suc- 
cessful translation is the key to better 



character animation because it gives 
you "the eye." 

Simply put, having the eye means 
you can look at something and see it 
to be either one of two ways: right or 
wrong. If it's right then you can move 
on to the next task. If it's wrong, you 
keep working on it until you make it 
right. So many times someone shows 
me something or e-mails me some 
animation sequence and asks my 
opinion. When it's so bad that I don't 
know whereto start with a meaning- 
ful critique I simply ask, "Does it look 
right to you?" 

Quake 3: Arena marks thefirst time 
I'vepersonally dealt with mo-cap out- 
side of the annual obligatory dog-and- 
pony shows at Siggraph and other trade 
events. I decided to try the mo-cap 
route because it's dead easy in 
Character Studio and for the simple rea- 
son our frame rate went from 10 FPSin 
Quake 2 to 15-25 FPS (depending on 
the animation). Turning to mo-cap 
makes sense as frame rates i n crease, 
si n ce keyf ram i n g th e su btl e an d n earl y 
imperceptible nuances of human old 
character animation, if not difficult, is 
at least time-consuming. The difference 
between a six-frame run cycle and a 13- 
framerun cycle is obvious to say the 
least. Another reason is that my fellow 
animator Kevin Cloud decided to con- 
centrate on other art aspects and leave 
me to do all the models and animations 
(nice of him, wasn't it?), so finding 
ways to save time became a priority. 

However, to say that I find myself 
forgetting how to keyframe because 
I've implemented mo-cap into the 
workflow isjust plain ludicrous. Mo- 
cap is a start and, if anything, a rough 
timing guide to assist your keyframing. 
I have yet to implement any motion- 
captured animation without at least 
some keyf ramed adjustment. This is 
not a problem for me. 



The No-Cap Experience 

Thefirst session I did was with Greg 
Pyros and his crew at Pyros Pic- 
tures. An amazing martial artist and 
actor, T.J . Storm, and a fellow actress, 
Bobbi, were the talent for my first run 
at making animations for the characters 
in Q3A. I learned a lot from the session, 
but sinceit wasmy firsttimel came up 
a littleshort in preplanning and accu- 



rately predicting the implementation of 
the data in my animations. I also didn't 
know Character Studio very well at the 
time and failed to exploit its strengths 
and allow for its shortcomings. Know- 
ing your pipeline and knowing all your 
software is crucial to successful mo-cap 
implementations. 

When I did my next session I went to 
House of Moves. The crew at HOM defi- 
nitely know their stuff and they were 
great to work with. I was quickly 
allowed to review the motions captured 
in crudewireframe playback to see if it 
was what I wanted. HOM also gave me 
videotape that matched the captured 
moves for both review and reference. 
Th ere were d i ff eren ces deal i n g wi th 
House of M oves, but the most over- 
whelming difference was that I suited 
up to do most of the motions myself. 

I consider myself to be in reasonably 
good shape so I wasn't afraid of the 
physicality of theshoot. Sincel'm a 
ham at heart I knew I could act well 
enough to get reasonably expressive 
motions based on what I'd seen T.J. do 
at the earlier shoot, and more impor- 
tantly, to get what I wanted from the 
characters I had already created. How- 
ever, I fully realize that I'm in a unique 
position to have more freedom than 
most artists at most companies. It's 
great being the modeler, animator, 
mo-cap director and mo-cap actor. I 
get to make sure I get exactly what I 
want and need to get the animations 
right. I enjoyed the HOM shoot so 
much that when I did my third session 
just recently I decided to be the "tal- 
ent" once again. 

This time however, I decided to try 
yet another company a whole lot closer 
to home. Located in the idyllic, rolling 
hills and fauna of Wimberly, Tex., near 
Austin, Kei and the crew at Locomotion 
Studios provided a comfortable, relaxed 
and professional atmosphere (except 
they didn't have any beer stocked). 

The animations I went for this time 
were more scripted than the animations 
I did at the other two studios, so it was 
more important for me to give a better 
performance. Instead being pieced 
together and used by the characters 
during real-time game play, these ani- 
mations would be plugged into the 
characters mostly as-is to be used for 
rendered cutscenes. This is a great 
exampleof mo-cap savingyou time on 
a project si nee the amount of work it 
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would take to make the subtle, expres- 
sive, realistic nuances! wanted in the 
animations would have taken far longer 
than I have to do them. Even in a 
worst-case scenario where the anima- 
tion is too wooden, keyframe augmen- 
tation can still save the day utilizing 
accurate timing if nothing else. 

In addition to offering immediate 
playback of thecaptured animation to 
seeif it waswhat I wanted. Locomotion 
took the process one step further by 
filming the captures in MPEG format, 
giving me a digital movie of the perfor- 
mance. This proved extremely conve- 
nient, more so than videotape. 

Extremely accommodating I ike the 
other studios, they were tolerant 
when I got wacky. For example, one 
thing I did for a particular character 
with a three-jointed leg was to walk 
backwards in order to give it a creepy 
quality when it walked forward. To 
support this, the guys at Locomotion 
quickly and easily played back the ani- 
mation in reverse, which allowed me 
to adjust my performance until I got it 
right. Oh, and do you want to know 
the best thing about the session at 



Locomotion? Soft reflector balls. Trust 
me, when you're covered with the 
hard ones, your potential for lots of 
pain while doing mo-cap is high. 



Just Where Do I Go for No-Cap? 

As I've said, time-saving is another 
attractive quality of motion cap- 
ture, but one that gets argued by artists 
because of the heavy cleanup required. 
That's what mo-cap service houses 
such as Pyros Pictures, House of Moves 
and Locomotion are for. You can let 
them do the clean up instead. By the 
time you've made the space, spent the 
money and trained theartiststo sup- 
port your own motion capture facility, 
the overal I cost wi 1 1 be hard to beat by 
simply going to an expert. Having dealt 
with three of these companies that pro- 
vide such a service in the past year has 
given me a fast and comprehensive 
understanding of the motion capture 
process. Understanding this process 
from start to finish is a necessity if you 
plan on using mo-cap. 
Therefore, consider the following as 



you tread down the motion-capture 
studio path. It could mean the differ- 
ence between success or fai I ure: 
Preplan. By preplanning I mean story- 
board, either literally or in your mind, 
each move you plan on getting. Ensure 
there are one or two people who track 
and manage the process from start to 
finish (you, the artist, being one of 
them). Also, come up with good file 
namesfor your motions. I usually stick 
to a six-character naming convention 
because it leaves room for different ver- 
sions (takes) later on. Calculate the 
amount of time in seconds you esti- 
mate each motion will last and then a 
total for the shoot. Use that number of 
finished seconds as a starting point 
when you negotiate a price. 
Getabid. Once your list isformed, start 
shopping around. Just be sure you 
have a very clear idea of what you 
want before presenting it to a mo-cap 
studio. Don't be afraid to start a bid- 
ding war. Th ese guys kn o w h o w 
important patronage and word of 
mouth are in our industry. 
Get GOOD TALENT. Although I really enjoy 
doing my own capture sessions, next 
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time I'll go back to paying some- 
oneelseto hit theground and 
writhe around in real...er, mock 
pain. I've found the key to get- 
ting a good performance is to 
find actors who are almost 
mime-like in their expressions 
and motions. Also remind your 
actor to go full speed and not 
slow down during performance. 
This may not be something 
readily apparent, but overacting 
or being overly conscious of 
devices tracking your every 
movement can be very obvious 
in the finished data. I've had to 
cut up to ten percent of the 
keyframes in any given mo-cap 
filedueto theactor being too 
measured in his or her move- 
ments, or make substantial 
tweaks because hands were used 
to break a fall (or to removeother glar- 
ing forms of anticipation). If you have 
the inclination and theability, I highly 
recommend doing your own motions at 
least once. It makes you appreciate what 
you ask the talent to do in all those hard 
reflector balls. 

Get THE MOTION YOU WANT. Not much else I 
can say here. You're the client. You're 
plopping down thecash (usually 30 
percent or so up front when you show 
up at the studio). You decide when the 
captured motion is right. Insist on a 
video or MPEG of the performance to 
review and just have around. If any- 
thing, it's something to show your boss 
and co-workers. 

Choose your in and out times. Basi cal ly, 
the in and out times are the points at 
which you want the motions you see 
on video to start and stop recording. 
This is obviously just so the mo-cap 
studio can cal cu I ate your total number 
of seconds captured, giving you exactly 
what you want when it happens. But 
never underestimate that little hitch or 
movement right at the beginning or 
end of a motion. While it's prudent not 
to pay for useless seconds of idle move- 
ment, you might be able to take a part 
of one motion and use it in combina- 
tion with keyframes somewhere else. 
Implement THE cleaned data. Once the 
data is delivered, plug it into your char- 
acter and see how it works. I did cap- 
tures for a character and decided I didn't 
like the implementation and just cut it 
from the list. Occasionally, somethings 
really do just look better on paper. 




Steed knows the importance of wearing many tiats dur- 
ing the motion-capture process, including this one cov- 
ered with reflector balls at Texas's Locomotion Studios. 



Pay THE GUY. Guess this is the bottom 
line, isn't it? Rates vary, but if you 
shop around, I i ke I 've al ready suggest- 
ed, you'll get the fairest price. The 
price of motion capture seems to keep 
dropping every time I get it done. This 
trend will no doubt continue as tech- 
nology advances. 

Speaking of cost, it is something to 
consider. For a small developer, using 
a mo-cap studio may be cost-prohibi- 
tive, but I'd encourage you to check it 
out anyway. All the people I've 
worked with have been extremely 
accommodating and flexible when 
trying to get my business. If you pre- 
plan appropriately and know exactly 
what kind of motions you want, the 
end cost will reflect your degree of 
organization. 

Another key to making a mo-cap ses- 
sion successful is to involve the anima- 
tor who will be using the data. Sure, 
th ose cl i pboard-carry i n g, coff ee-cu p- 
toting producer types have their uses 
and can baby-sit the fiscally irresponsi- 
bleartist if they like, but at least oneof 
theartists who will be working with 
the fruit of the session needs to be pre- 
sent during the shoot. 



Can t Ue All Just Get Along? 

I ot too long ago, I read a couple 
1 negative commentaries on 
motion capture in a telephone-book- 
sized tome dedicated solely to charac- 
ter animation. This was the first time I 



ever heard mo-cap referred to 
as "Satan's Rotoscope." What a 
load of crap. 

I hear statements I ike this 
and I think of that e-word — 
ego. Teams of people are 
responsi ble for games today, 
not individuals. Not to explore 
the possibilities and benefits of 
a new technology because you 
want the pleasure of proclaim- 
ing you did it all from scratch is 
part of th e i n an i ty th at resu I ts 
in very late products being 
shipped. Sure, given all the 
time in the world, any anima- 
tor worth his salt can create 
convincing and supremely real- 
istic ch aracter an i mat i o n . W el I , 
we all know how much time we 
have to do our animations, 
don't we? 
But, what the hey. Let's just say for a 
second that mo-cap is evil. The bane of 
thereal artiste. If that's the case, then 
why not just toss that computer alto- 
gether and go back to traditional eel 
art animation and just scan the art in? 
Oh, but that would mean you'd have 
to use a scanner. Since that evil con- 
traption digitally captures images that 
could be used in game art, such as tex- 
ture maps, we should probably get rid 
of that bit of demonic technology as 
well. While you're at it, what about 
digital cameras, model digitizers, 
heck.. .even photographic reference of 
any sort? Maybe all example of mod- 
ern tech n i ques or tech nologies that 
assist the artist in his ability to meet 
his deadlines with work that (gasp) is 
sometimes better than he could have 
achieved on his own should be con- 
signed as products of the nether realm. 

The purists would secretly be not too 
u n h appy about th i s because th en th ey 
could weed out the real artists from 
those pretentious wannabe keyboard 
jocks. Then they could beat their chests 
in pride and reaffirm their prodigious 
training and stature. 

Technophobia has no place in 
today's world of computer game devel- 
opment. Motion capture is hereto stay 
an d wi 1 1 an t i q uate keyf ram i n g about as 
quickly as electronic documents have 
turned our work environment into a 
"paperless" office. In the right hands, 
mo-cap is the perfect way to aid and 
enhance the keyframe animator, not 
replace him. ■ 
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A Tale of Two Channels 

PC gaming appears to be the technological peak of game development. 
However, the advent of Sega's Dreamcast, Sony's marketing of Playstation 
2 technology, and the intriguing prospects of Nintendo's Dolphin system 
havehelped to promote greater anticipation for the con sole. 



Even Nintendo's Game Boy has shown 
phenomenal growth in 1999 and is 
attracting new titles and developers to 
th e CO I or versi on, while then ext- 
generation, 32-bit Game Boy "Advance" 
i s si ated for rel ease I ate n ext year. Al I 
these comparisons of platform tech- 
nologies asi de, th e bi ggest obstaci e to 
success in the PC gaming market is the 
structure of the PC business, which is 
built around the sales of PC hardware to 
businesses and education outlets. 
Games may be ubiquitous, but the PC 
industry still sees the game industry asa 
marginal interest, and sometimes solely 
asameansto sell the latest CPU. 
Exam i n i n g th e market of con sol e game 
users and the channels for con sole prod- 
ucts is a sobering lesson in how far the 
PC industry has to go to become con- 
sumer-savvy. 

The PC game business has always 
been hampered by a lack of shelf space 
and sufficient sales outlets. This situa- 
tion is unlikely to be resolved while the 
market remains driven bytheupgrade 
cycles of Microsoft and Intel. In the 
meantime, the console gaming market 
is benefiting from penetration into 
both traditional retailing channels and 
existing PC sales channels. 



Channels Young and Old 

hileonlinesalesof PC products 
is considered to be a hot area of 
growth, the vast majority of sales still 
come from third-party retailers and dis- 
tributors who rely on their expertise 
with applications to serve a desired 
market. It's rare to find a reseller or sys- 
tem integrator that is focused on 
games. In contrast, console products are 
predominantly retail-based and require 
no third-party support or intervention. 
For PCs, there are more than 100,000 



companies in the U.S. alonethat act as 
middlemen for computer manufactur- 
ers, and who supply systems, upgrades 
and services to users. In such a large, 
competitive market, specializing in 
hardware sales to game players would 
make little sense, and trying to compete 
i n th e aren a of PC gam i n g software i s 
unlikely to enliven any reseller's bot- 
tom line. 

By contrast, a fully configured net- 
work of systems for a small business or 
corporate customer has potential for 
lucrative service and support contracts, 
or may be solely beneficial in selling a 
reseller's software expertise. So, while 
the $125 billion in sales that the PC 
channels produce is an impressive 
number, it's spread across a vast mix of 
deal ers an d resel I ers. Th ese con si st of 
value-added resellers (VARs), retailers, 
distributors, systems integrators (Sis), 
mom-and-pop stores, and everything 
from a single-person consultancy to big 
service companies such as EDS. Stacked 
up against these hardware-driven dis- 
tribution channels is a console business 
driven by cute game characters and 
mass-market promotions. 

Simply put, PC channels are relative- 
ly young compared to the retail chan- 
nels that console games have penetrat- 
ed. PC channels are as old as the PC, 
while retail channels date back to 
bef re t h e el ect ro n i c age. Th i s po i n ts 
out the gaping chasm of consumer 
savvy between traditional PC sales 
ch an n el s, an d th e retai I ers th at th ri ve 
on N64, PSX, and Game Boy products. 
Furthermore, the next generation of 
console products promises to constrict 
the PC gaming market by providing 



powerful platforms with multimedia 
and on line capabilities. Next-genera- 
tion consoles may not be PCs, but they 
don't aim to sit on someone's office 
LAN, either. 



The Console Player's Choice 

Atthethird annual Electronic 
Gaming Summit this past August, 
Ziff-Davis announced the results of the 
Video Gaming in America research 
report. This report found that purchase 
impact is influenced more by brand 
power of a character or game than by 
the knowledge of the publ isher or 
developer. Surprisingly, the buying 
habits of game players, according to the 
report's findings shown in Chart 1, 
point out their preference for discount 
stores where impulse buying and pric- 
ing play a key role. Console games seem 
to have better branding and get into 
the pi aces where the most buying 
occurs. This is despite the fact that at 
places I ike Wal-Mart, PC games have to 
be priced below $20 to qualify for sig- 
nificant sales. If that weren't bad 
enough, the reputation of consoles as 
high -technology products, which is 
reflected in the sales of console games 
through computer superstores. 

The other advantage that the console 
market has is rentals. "Core" game play- 
ers (defined in the report as those con- 
sumers who purchase two or more 
games per month) are averaging more 
than three rentals per month, while 
"casual" players (defined as those who 
purchase fewer than two games per 
month and play fewer than four times 
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per week) average about 1.4 
rentals per month. The real 
kicker is purchase rates after 
rental are 84 percent and 65 
percent respectively for core 
and casual players. Video 
rental outlets can devote any- 
where from 10 to 20 percent 
of thei r shelf space to games, 
but generate i n excess of 
those figures in percentageof 
revenues from rentals. There 
is really no mechanism in 
place, or likely to be put in 
place, to create the same 
rental opportunity for PCs. 
The PC always has the benefit 
of the limited demo software 
package bundled with game 
magazines and aval I able for 
download, but these options 
pale in comparison to being 
abl e to take a game home to 
play in full for three days. 

Another interesting find- 
ing in the report is the influences on 
players' purchasing choices across core 
players, casual players, and "average" 
players (defined as consumers who pur- 
chase fewer than two games per month 
but play four or more times per week), 
shown in Chart 2. Friends, television, 
and in-store game demos played a key 
rolehere. In-store demos of PC games 
are unlikely to happen anytime soon, 
unless you have a publisher with a very 



CHART 1 . Game players are shopping across all outlets (source: Ziff-Davis). 




significant marketing budget to spend, 
or PCs end up costing $100, and you 
can load 10 games within 60 seconds. 



The PC Branding Problem 

PC games, with some exceptions, 
ten d to be more soph i sti cated si m- 
ulationsand immersive environments. 
As a result, PC games lack some of the 



CHART 2 . Consumers' sources for videogame purctiasing information (source: Ziff-Davis) 




"cute" character brands of console 
games. At a more specialist level, the PC 
has programmers I ike John Carmack 
and designers like Sid Meier, but the 
console industry has Shigeru Miyamoto 
and David Perry. 

To reconcile these two worlds, PC 
game channels have to get closer to 
the console market in terms of mar- 
keting sophistication and audience 
appeal. PC gaming will not ultimately 
die, but it will become cor- 
nered, and that will affect 
the flow of new talent into 
the industry. That in turn 
would affect innovations in 
technology and titles. It 
I ooks I i ke the console mar- 
ket has finally grown up, 
and now it's timefor the PC 
market to do the same. But 
it won't happen until the 
gaming industry figures out 
how to break the infrastruc- 
ture of PC sales channels. 

Recently, the Good Guys 
chain of electronics stores 
announced it was ceasing PC 
sales, CompUSA said it would 
close some of its stores, and 
OfficeMax has felt the drain 
of lower PC prices and prof- 
its. Meanwhile, displays of 
console games and hardware 
in CompUSA stores continue 
to grow. ■ 
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ame console programming is largely a secret 
art. The technology and APIs are kept hidden 
by nondisclosure agreements, and you won't 
find development kits for game con soles at 
your local software store. Asa result, pro- 
gramming for game consoles is something 
you just don't hear much about. 
While specific techniques for program- 
ming Nintendo's current game console are well-known within that particular devel- 
oper community, they are virtually unknown among PC developers, or developers 
looking to do cross- platform titles. This article will give you some insight into the 
inner workings of the Nintendo 64 (N64). Much of what I'll discuss in this article 
hasn't even been released to authorized N64 developers. Nintendo has chosen to 
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pull back the covers to help 
devel opers squeeze th e I ast 
ounce of performance out of the 
machine. We hopethat this arti- 
cle will help N 64 developers do 
just that, and encourage other 
devel opers to explore N 64 pro- 
gramming. 

After a quick discussion of the 
N64 architecture, we'll dig 
down deep and design some 
custom Reality Signal Processor 
(RSP) microcode, which tessel- 
lates a Bezier surface as shown 
in Figure 1. The RSP is a very 
powerful custom chip in the 
N64, and until now thedetails 
of programming this chip have 
been kept secret. In a sense, we 
at Nintendo have decided to let 
the cat out of the bag. You'll get 
a feel for the incredible power of this 
chip and see why N64 is capable of 
great 3D graphics with features that 
still aren't available in consumer 3D 
cards. 



Nintendo 64 Architecture 

The Nintendo 64 isdesigned around 
two main processing components 
(Figure 2). These two elements area 
M I PS R4300i CPU , and the Real ity Co- 
Processor (RCP), which is a custom chip. 
Th e si m p I i ci ty of t h i s arch i tect u re 
makes N64 programming very straight- 
forward. In addition to these processors, 
the N 64 contains 4M B of Rambus 
DRAM (RDRAM), four controller ports, 
and a cartridge port. The memory is 
expandable and a 4MB Expansion Pakis 
currently available. 

The N64's custom RCP run sat 
62.5MHz. It ispri- 




FIGURE 1. This Bezier surface has been tessellated by 
the microcode we develop in this article, and rendered 
by a Nintendo 64. 



takes this information, loads the tex- 
ture cache from RDRAM, and renders 
fully M IP-mapped, anti-aliased, Z- 
buffered triangles to the frame buffer. 
This design I eaves the CPU free to per- 
form physics calculations, advanced 
artificial intelligence, sound process- 
ing, and other game functions. 

RSP Architecture 

The RSP is modeled on a general- 
purpose 32-bit RISC processor. It 
includes 4KB of memory for code 
(I M EM ) and 4KB of memory for data 
(DM EM). Programs which execute on 
the RSP are known as microcode. 
Nintendo provides a standard suite of 
microcode to all N64 developers, 
including 3D transformation and light- 
ing code, line-drawing code, sprite rou- 
tines, and audio processing. Due to 



marily composed 
of two parts: the 
Reality Signal 
Processor (RSP) 
and the Reality 
Display Processor 
(RDP).TheRSP 
processes display 
lists which are sent 
from theCPU. It 
performs all 
matrix and vertex 
computations and 
outputs triangle 
commands to the 
RDP.TheRDP 




special features of the RSP, it is 
very well -suited for computa- 
tionally heavy tasks such as 3D 
graphics calculation and audio 
mixing. 

In addition to 32 32-bit 
scalar registers, the RSP 
includes 32 128-bit vector reg- 
isters. These vector registers 
can be addressed in a variety of 
ways, but they are ideally used 
as eight shorts (also called vec- 
tor slices). Each slice has a 48- 
bit accumulator associated 
with it that can be used to 
store intermediate results. 
Using the vector registers and 
accumulators, a vector opera- 
tion can be performed which 
multiplies two vectors and 
adds the result to the current 
accumulators, giving 16 calculations in 
one cycle. 

The RSP can actually execute a vector 
operation and a scalar operation each 
cycle. This means that it's possible to 
do 17 calculations per cycle. With care- 
fully tuned microcode, it ispossibleto 
reach a maximum of just over one bil- 
lion operations per second. 

The Nicrocode 

This high-speed programmable 
arch i tecture was very forward- 
thinking at theti me the Nintendo 64 
was designed. It has enabled Nintendo 
to provide a set of standard microcode 
libraries which make 3D programming 
easier for the novice. At the same time, 
el ite programmers are able to code up 
special routines which are optimized 
for their own games or enable unique 
functionality. 
During the life span 
of the N 64, the 3D 
performance has 
nearly doubled as a 
result of microcode 
optimizations. 



FIGURE 2 . The Nintendo 64 architec- 
ture is simple and elegant. 



FIGURE 3. An example command 
from the standard N64 3D graphics 
microcode. This command turns on 
texture mapping using a specific tex- 
ture tile. 



Nicrocode 
Execution 

First let's talk a 
little about the 
structure of microc- 
ode and how to use 
it. Microcodeisexe- 
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cuted through the use of an RSP 
task. Tasks are command lists 
(grap h i cs d i sp I ay I i sts o r au d i o 
commands) which indicatea 
series of operations for the 
microcode to perform. They are 
executed in parallel with the 
CPU. In order to start an RSP 
task, you create the command 
list and pass it to the RSP along 
with pointers to the microcode 
and various buffers that the 
microcode needs. Then you call 
a simple function to start RSP 
execution and control is imme- 
diately returned to the main pro- 
gram while the RSP begins pro- 
cessing commands. 

The RSP can communicate 
with the RDP or CPU during 
execution if necessary. For 
example, most versions of the 3D 
microcode communicate with the 
RDP, feeding it triangles and other 
data to render to the frame buffer. 
Other versions of microcode commu- 
nicate with the CPU when data is 
ready. For example, the Z- Sort microc- 
ode can beset up to alert the CPU 
after a number of objects have been 
processed so that the CPU can work 
on these objects in parallel. When the 
RSP completes the task, it signals the 
CPU so that the user program can 
send the next RSP task or use this 
information for synchronization. 




The Command Loop 



The microcode command loop 
sequentially goes through com- 
mands which have been DMA'd into 
DM EM from the command list. Simi- 
lar to assembly language instructions, 
the commands have bitfields which 
indicate the RSP function desired. In 
the microcode command loop, the 
opcode and subopcode bitfields are 
masked off and used as an offset into 
thefunction jump tables (also stored 
in DM EM) to determinethe IM EM 
function location. 

In the standard graphics microco- 
des, each command is a 64-bit double- 
word. The opcode and subopcode are 
contained in the upper bits, and lower 
bits are reserved for data being passed 
as function parameters as shown in 
the example in Figures. The data bit- 
fields are masked off in the main loop 



and stored in separate registers before 
jumping to thefunction requested. 



The DMA Engine 



The RSP includes a set of registers 
which control the DM A engine. 
Since there may be multiple requests 
for DMA pending, the microcode must 
check the DM A Busy register before 
submitting its request. If a request is 
being processed and there is already 
another request pending, the micro- 
code must wait 
before sub- 
mitting a 
request. A 
request is 
made by 
altering the 
DMA Source, 
DMA Destination 
and DMA Length 
registers. Once the 
length is written to the 
DMA Length register, the 
DMA enginequeuesthe 
request and beginsthe 
transfer if no requests 
are pending. The 
transfer executes in 
parallel with the 
RSP so control 
is immedi- 
ately 
returned 
to the 
micro- 
code. 



Using Curved Surfaces 

With this basic under- 
standing of the N64's 
workings behind us, let's move 
on to the main focus of this 
article, using curved surfaces. 
Curved surfaces are not sup- 
ported in the standard N64 
microcodes. But if you want to 
render curved surfaces, it makes 
a lot of sense to do the heavy 
computations required on the 
vector processor. Now, we're 
not actually going to render 
curved surfaces. We'll take a 
curved surface representation 
and tessel I ate the surface into 
polygons which theN64 then 
renders. 
For our purposes here, we are 
going to use Bezier surfaces. A Bezier 
surface is a curved bicubic surface, sim- 
ilar to Hermite surfaces, B-splinesur- 
faces, and NURBS. The Bezier is mathe- 
matically complex enough for us to be 
ableto create interesting surfaces, 
while not being so difficult to compute 
that we're only going to be ableto do a 
couple per frame. If you need to brush 
up on curved surface technology, 
check out the list of references at the 
end of this article. 

There are a number of algorithms 
we could use to tessel late a Bezier sur- 
face. First, let's quickly look at the 
standard equation and 
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Bezier Surface Equation 

ABezier surface is a parametric sur- 
face (u,v = [0,1], [0,1]) defined by 
its 16 control points p-- which form a 
4x4 grid, as shown in Figure 4. The 
common form for representing this 
surface is: 



o(u,v; 



ThefunctionsBj(u) and Bj(v) are the 
Bernstein polynomials which are also 
used for Bezier curves. 

The edges of a Bezier surface are each 
Bezier curves. Si nee only the end con- 
trol pointsof Bezier curves lie on the 
curve, wecan extrapolate that thecor- 
ner points of the surface are the only 
control points which Neon the surface. 
All twelveof the other control points 
influence the shape of the surface, but 
are not on the surface itself. For this 
article, we'll create a microcode that 
tessellatesa Bezier surface into an 
8x8 grid of quadrilaterals. 



Tessellation by Evaluation 

Th e most d i rect way to si i ce a 
Bezier surface into polygons 
i s by cal cu I ati n g th e above Q (u ,v) 
double summation on a regular 
grid. Performing this in a very 
optimized way, each surface 
vertex we cal cu I ate req u i res 54 
additions and 108 multiplies. 
That's a lot of work to do 
when we're planning to create 
a 9x9 grid of vertices. 



Central Differencing 

The way we're going to generate 
points on the Bezier surface in 
th i s arti cl e i s th rough th e use of central 
differencing. Central differencing gives 
us an easy way to find the midpoint of 
a Bezier curve without having to keep 
track of control points for each sub- 
curve. Wecan split the edge curves at 
their midpoints, and then split the sur- 
face across th ese m i d po i n ts to create 
four subsurfaces. This process can be 
repeated recursively to create an arbi- 
trarily fine mesh. (For details on this 
algorithm please see the previously- 
mentioned article on Gamasutra.com, 
or Brian Sharp's series of articles on 



curved surfaces, June-July 1999.) 

The central differencing algorithm 
has a hefty initialization cost due to 
the computation of second partial 
derivatives (Quu, Qvv, Quuvv) at each 
corner control point. But every curve 
subdivision after that will only cost us 
18 additions and 18 multiplies. The 
memory footprint is 24 bytes per subdi- 
vision, and there are 77 subdivisions 
necessary to create our mesh. This will 
fit in our 4KB DM EM nicely. 

Writing the Tessellation Microcode 

I ow that we've chosen the algo- 
rithm to tessel I ate the surface, 
let's get back to work on the microcode 
itself. Thefirst things 
we need to fig- 
ure out are the 
commands 
we need 
and the 
com- 
mand 
struc- 
ture. 
We're 
going to 
use a 
64-bit 
double 
word for our 
command size. 
That will give us 
plenty of 




room to store the data for each com- 
mand inside the instruction. Thecom- 
mands and parameters necessary for 
our tessellation microcode are: 

1. Set RSP segment (segment number, 
physical address). 

2. Load control points (segment 
address). 

3. Perform tessellation. 



^. Save surface vertices (segment 

address). 
5. End display list. 
I'll describe these commands further in 
a moment. 

Since we only have five commands, 
we can just use a 3-bit field for the 
opcode. Fortunately, thestandard 
graphics microcodes all use a 3-bit 
opcodefield and 6-bit subopcode field, 
so we'll use that. But we'll just wedge all 
our instructions into thesubopcodesfor 
one primary opcode. Then wecan reuse 
a lot of the main command loop rou- 
tines from thestandard microcodes, 
including thedisplay list DMA routine 
that loads commands into the DM EM 
buffer for us. The low bit of the opcode 
field and subopcode field are not used. 
Since microcodefunction addresses 
stored in DM EM take up two bytes 
(address range 0-4095), our jump table 
should be indexed on even bytes only. 
Not usingtheselow bits ensures that we 
have an even index without performing 
a shift or multiply for every command. 

The parameters for our commands are 
pretty straight-forward. The most com- 
plicated command sets a segment regis- 
ter for address computations. It requires 
a segment number and physical address. 
We're using a 16-address segment table 
in the RSP, so it'll take four bits to hold 
the segment number. The addresses are 
32 bits, so we'll use the second half of 
the 64-bit double word for the address. 
Then we'll usethe upper nine bits for 
the opcode and sub- 
opcode fields 
and follow 
it with 
four bits 
for the 
segment 
address. 
You can see 
our command 
structure in Figures. 

Getting Data In and Out 

I eforewe code up the tessel I ati on 
^algorithm, let's figure out how to 
get data in and out of DM EM . The "set 
RSP segment" command fills an entry 
of our 16-entry segment/ offset table, 
which isstored in DM EM . Thistable 
makes some programming tasks easier, 
such as swapping the frame buffer each 
frame. The segment table stores 24-bit 
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FIGURE 5 . Our command structure is similar to 
the structure of standard N64 microcode com- 
mands. We use this structure for all of our com- 
mands. 



offsets which are added to any address 
sent to the RSP. The segment table 
index is stored in bits 24-27 of the 
addresses passed in. The low 24 bits of 
the segment address are added to the 
24 bits stored in the segment table. 
Si nee our physical address range is 
0-0x007fffff (8M B), 24 bits is enough. 

Prior to tessellation we need to load 
the control points into DM EM . Our 
"load control points" command simply 
takes an address as a parameter. The 
address is passed to the segment 
address translation routine, which uses 
the segment table to convert the 
address to a physical address. The DMA 
engine is called to bring the 16 control 
points into DM EM from this physical 
address. 

After tessellation, we need to save 
the surface vertices we've computed, 
using the "save surface vertices" com- 
mand. We'll pass in an address and the 
segment address translation routine 
will convert it to a physical address. 
That physical address is used to pro- 
gram the DM A engine to copy our 81 
surface vertices to RDRAM. 

The "end display list" command sim- 
ply flags the RSP to quit. It executes a 
break, which signalstheCPU, and 
alerts our main program. 



Data Formats 

The first thing our "perform tessella- 
tion" command does is perform a 
simpletranslation from control point 
format to surface vertex format. So let's 
talk about these formats. 

The Nintendo 64's standard vertex 
format uses 16-bit coordinate ranges, 
which are sl5 quantities (one sign bit 
and 15 integer bits). This gives vertex 



coordinates an effective range 
of 32KB. It makes sense for 
us to use th i s same format for 
control points, but since we're 
just tessellating, we really only 
need the point position. Rather 
than wasting the extra space 
for colors and texture coordi- 
nates when we DMA the con- 
trol points into DM EM, our for- 
mat will only represent the X, y, 
and z position assigned shorts. 

The surface vertex format is 
more complicated. The central 
difference algorithm describes 
four sets of val ues that each ver- 
tex needs to track. These are: 

1. Q(u,v): Position 

2. Ouu(u,v): Second partial derivative 
in u at this vertex. 

3. Ovv(u,v): Second partial derivative 
in V at this vertex. 

^^ Ouuvv(u,v): Second partial derivative 
in u of the second partial deriva- 
tive in vat this vertex. 
All of these val ues are vectors of X, y, 
and z. Si nee the vector slice size of the 
RSP is 16 bits, and the control point 
coordinates are 16 bits, we're going to 
stick with 16 bits for these coord in ate 



valuesas well. We'll have to tweak our 
math to minimize overflow and under- 
flow, but it will pay off in performance. 

One final note on formats. Each vec- 
tor register contains eight vector slices. 
But each of our points contains three 
val ues (x, y, and z). We're really just 
going to make things confusing if we try 
to stuff two of three coordinates from 
one vertex into a vector register, along 
with two other vertices. So let's insert a 
junk (we'll call it j) field at the end of 
each of these vertices. This will also give 
us much better alignment in DM EM. 

Now that we have our formats 
defined as in Listing 1, it's a simple task 
to convert from one to the other. Actu- 
ally, all we need to do is copy the 64 
bits from each corner control point (x, 
y, z, and j) into the beginning of each 
corn er su rf ace vertex . 



Corner Initialization 

ow we need to compute the sec- 
ond partial derivatives described 
above for each corner of the surface. 
Fortunately, the second partial in u 
and the second partial in vat each 



LISTING 1 . Formats for data storage in DMEM. The j fields are unused, we 
include them for data alignment. 



struct ControlPoint { 

sl5 X, y, z, j; 

}; 



struct SurfaceVertex { 
sl5 
sl5 
sl5 
sl5 



qx, qy, qz, qj; 

quux, quuy, quuz, quuj; 
qvvx, qvvy, qvvz, qvvj; 
quuvvx, quuvvy, quuvvz, quuvvj; 



}; 




LISTING 2 . Pseudocode for computing Q.uu(o,o) and Q.vy(o,o) using vector 
processing. , 



# Load the vector registers with point data 
vload vectora, P[0,0], P[0,0] # = 

vload vectorb, P[1,0], P[0,1] 
vload vectorc, P[2,0], P[0,2] 



X y z J, X y z J 



# Do vector computations to simultaneously compute quu and qvv. 



vadd 


vectord, vectora, vectorc 


# D = A+C ■ 


vmul 


vectore, vectorb, vconst[5] 


# E = B*(-2) I 


vadd 


vinter, vectord, vectore 


# inter = A-2B+C ■ 


vmul 


vOO, vinter, vconst[3] 


# vOO = 6*(A-2B+C) ' 


vstore2 


vOO, vOOuu, vOOvv 


# Store results to uu and vv fields 
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corner control point can be computed with similar equa- 
tions that use different points. Here are the equations to 
perform at control point (0, 0): 



together the and Qw computations. That's because both of 
these are very similar computations. For Quu and Quuw we're 
doing this: 



o,,(ao) = 6(Po, 

Q,,(aO) = 6(Poc 



■ 2Pio + P20) 



2P01 + P02) 



We need to do this computation in x, y, and z for each 
equation. This is a great place to take advantage of vector 
processing. We'll do this operation in parallel, computing 
both equations for X, y, and z simultaneously. First, we load 
both sets of control point positions into the vectors, as 
shown in pseudocode in Listing 2. Then just a few vector 
computations are performed and all coordinates are simul- 
taneously calculated. 

Note that we have the constants -2 and 6 stored in a vec- 
tor constants (vconst) register, which makes it easy to multi- 
ply each slice in another vector by each 
scalar. Using vector processing we've 
reduced two additions and two 
multiplies for each of six coordi- 
nates to just two additions and 
two multiplies total. 

We can perform this same 
process to compute Quuw 
But we'll have to pair up 
the operations. We have 
four control points, the 
corner points, which we 
need in order to calcu- 
late Quuw We can com- 
pute two separate con- 
trol points 

simultaneously by jam- 
mingthem into thesame vector and doing 
vector operations. So we'll perform this 
process twice in order to compute Quuw for 
all four points. 



Surface Subdivision 



For code simplicity, we're going to subdivide 
the surface iteratively, not recursively. We're going to 
subdivide many times, so let's make a function out of it. 
What do we need to pass to thisfunction? Well, we'll need 
the data for the endpoints of the curve we're spl itting, and a 
du value which is the distance in parametric space from the 
midpoint to the endpoint. This is 0.5 for our first subdivi- 
sion. For simplicity, we'll pass in the value (du)V2 so we 
don't have to compute the square and multiply by one-half 
each time we use the function. We'll also stuff this value in a 
vectorsliceso that wecan use it in vector computations. 
We'll call the vector which contai ns this value vecdusqhalf. 
Ourfunction ends up looking I ike this (there will beonefor 
u-curvesplits, and onefor v-curves): 

void tesselSubdivide[U I V] (Vertex vO, Vertex vl, Vector vecdusqhalf) 
ThemicrocodeforthetesselSubdivideU function appears in 
Listing 3. Thefunction tesselSubdivideV will be very similar. 

The first thing you'll notice in this code is that we block 
together the Quu and Quuw computations. We also block 



QuuK) + Quu(Ul) 

2 

Quuw(Uo) + Quuw(Ui) 




The computations for Q and Qw depend on the prior com- 
putations, so we do them second. They look I ike this: 

QK.) = ^^^i2^^-(dusqhalf*Q„„K,)) 



Most of the opcodes you see in the microcode 
listing make intuitive sense. But onethat 
bears explaining is vmudm. The RSP pro- 
vides many multiplication opera- 
tions. They vary depending on the 
sign of the operands and whether 
the operands are fractions or 
integers. The vmudm opera- 
tion performs multiplica- 
tion of signed integers 
by unsigned fractions. 
The resulting integer 
part of each vector slice 
computation is stored in 
the destination vector reg- 
ister (first operand), and 
the 32-bit integer/fraction 
results are stored in the 
accumulator slices. 
This microcode currently is 
not optimized for dual process- 
ing, nor for accumulator storage 
of intermediate results. Vector 
loads and stores are scalar opera- 
tions, so we could easily tighten this 
microcode up by executing loads and stores in parallel with 
vector operations. 



Performance Figures 

Calculating a regular grid of points on the Bezier surface 
using the standard double sum equation is a not a very 
efficient way to tessellate. Using floating-point arithmetic on 
th e C PU , th i s process took 272,500 C PU cycl es. W h i I e cen - 
tral differencing has a large performance cost at initializa- 
tion, the subdivision step is very fast. Implemented on the 
CPU, it takes 70,400 CPU cycles to tessellate our surface. 

When we moved this algorithm to the RSP, we made some 
sacrifices. We used 16-bit fixed-point arithmetic and took a 
hit for DM A-ing data to and from the RSP. But our algo- 
rithm, including RSP load and save time, runs in just 16,600 
CPU cycles. AndtheCPU itself is free during this process to 
do other computations. 
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LISTING 3 . Microcode for the tesselSubdivideU routine. 



N64 Optimizations Keep the 
Platform Fresh 

We've examined how Bezier sur- 
faces can be innplennented on 
the N 64 using a central difference tes- 
sellation algorithm in microcode. The 
payback we got for choosing a more 
efficient surface tessellation algorithm 
and pushing it onto the RSP was sub- 
stantial. 

Technically, the N64 is still a power- 
house. Programming the microcode 
and taking advantage of vector pro- 
cessing gives developers the ability to 
implement algorithms that aren't fea- 
sible on much bigger and faster CPUs. 
In addition, learning to program the 
N 64 now will give developers a big 
advantage when it comes to next-gen- 
eration console development (includ- 
ing Nintendo's upcoming system, cur- 
rently known as Dolphin), many of 
which use vector processing. If you're 
interested in becoming an N64 devel- 
oper, or if you are an N64 developer 
and you want to know about microc- 
ode development kits, please contact 
Nintendo by sending e-mail to 
supportcgnoa.com. ■ 

Books 

Watt, Alan, and Watt, N\ark. Advanced 
Animation and Rendering Tectiniques: 
Tlieory and Practice. New York: ACM 
Press, 1992. 

Periodicals 

Clark, J. H. "A Fast Scan-Line Algorithm 
for Rendering Parametric Surfaces." 
Computer Graptiics Vol 13 No. 2: pp. 
289-299. 

Game Developer ' 

Sharp, Brian. "Implementing Curved 
Surface Geometry" Oune 1999) and 
"Optimizing Curved Surface Geometry" 
Oulyi999). 

Gomosutra 

For a detailed derivation and compari- 
son of Bezier surface algorithms, see 
the expanded version of this article at 
http://www.gamasutra.com. 

Bezier Surface Microcode Source 

If you're a Nintendo 64 developer, log 
on to Nintendo's developer web site at 
https://www.warioworld.com. 



# tesselSubdivideU 
# 

# Subdivide this curve in the U direction 



# Surface Vertex structure offsets 



.symbol 


VERTEX.POS, 




.symbol 


VERTEX.UU, 


8 


.symbol 


VERTEXJV, 


10 


.symbol 


VERTEX.UUVV, 


24 


# Register aliases 




.name 


pnew, 


$10 


.name 


pminus, 


$11 


.name 


pplus, 


$12 


.name 


vecdusqhalf , 


$v6 


.name 


vecminus, 


$v7 


.name 


vecplus, 


$v8 


.name 


vecuus, 


$v9 


.name 


vecuushalf , 


$vlO 


.name 


vecposvvsinter, 


$vll 


.name 


vecposvvshalf , 


$vl2 


.name 


vecmulleduus, 


$vl3 


.name 


vecposvvs, 


$vl4 




.ent tesselSubdivideU 



# Position of output surface vertex (u) 

# Position of input left surface vertex (u-du) 

# Position of input right surface vertex (u+du) 

# Vector which contains 0.5*du*du in slice 

# Vector for storing left surface vertex info 

# Vector for storing right surface vertex info 

# Temp vector for UU and UUVV computation 

# Final results of UU and UUVV computation 

# Temp vector for POS and VV computation 

# Temp vector for POS and VV computation 

# Temp vector for POS and VV computation 

# Final results of POS and VV computation 



tesselSubdivideU : 



# Do quu and quuvv computations together 
Idv vecminus[0], VERTEX_UU(pminus) 
Idv vecminusES], VERTEX_UUVV(pminus) 
Idv vecplusEO], VERTEX_UU(pplus) 
Idv vecplus[8], VERTEX_UUVV(pplus) 
vadd vecuus, vecminus, vecplus # Add endpoints 
vmudm vecuushalf, vecuus, vecconst[l] # Mul by one-half 

# Do qpos and qvv computations together 
Idv vecminusEO], VERTEX_POS(pminus) 
Idv vecminusES], VERTEX_VV(pminus) 

Idv vecplusEO], VERTEX_POS(pplus) |H 

Idv vecplusES], VERTEX_VV(pplus) ^ 

vadd vecposvvsinter, vecminus, vecplus # Add endpoints 

vmudm vecposvvshalf, vecposvvsinter, vecconstEl] # Mul by one-half 

vmudm vecmulleduus, vecuushalf, vecdusqhalf EO] # uus/2 *(du''2)/2 

vsub vecposvvs, vecposvvshalf, vecmulleduus # Subtract... 



# Store everything 

sdv vecuushalf EO] 

sdv vecuushalf E8] 

sdv vecposvvsEO] , 

jr return 

sdv vecposvvsES], VERTEX_VV(pneu) 

.end tesselSubdivideU 



VERTEX_UU(pnew) 
VERTEX_UUVV(pnew) 
VERTEX_POS(pnew) 
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eveloping games for consoles often requires tight 



resource management. Trying to fit all your 



textures, sounds, and polygons onto the 



machine is difficult enough, but then 



consider that your monsters, explosions. 



and bullets must live in this same place 
along with your program code. It's a tight fit. 



But resource management is much 
more than j ust deal i ng with size con- 
straints. You also have to properly allo- 
cate and free resources, which, if 
ignored, can quickly turn into hiding 
places for numerous bugs. Fortunately, 
there are ways to deal with these prob- 
lems. It just requires planning and 
implementing some helpful tools. 

First, let'sseewhat we're getting our- 
selves into when we start talking about 
developing for a console. For this article, 
my focus is on the main memory, so 
we'll ignore video and sound memory. 

The current champ of the console 
wars is the Sony Playstation, which 



means that if you're thinking about 
developing for consoles, you're proba- 
bly considering this system. The 
PlayStation's massive consumer market 
i s th e good n ews, but th e bad n ews i s 
that its market is the only big thing 
about it — the system itself is very lim- 
ited when it comes to resources. The 
Playstation is a small system with only 
2M B of primary memory. The 
Nintendo 64 isn't much better at 4MB. 
The newest kid on the block, the Sega 
Dreamcast, comes to the table with a 
more impressive 16M B of memory but 
itwill sometimes have WindowsCE 
taking a si ice of that space. (Also, the 



recently-released specifications for the 
Sony Playstation 2 reveal thatthesys- 
tem will have 32MB of main memory. 
But since it's currently in development, 
that might change.) In other words, 
the PC has a huge leg up on consoles as 
far as main memory goes and it doesn't 
look as if that will end anytime soon. 

Keeping these restrictions in mind 
when developing a game is critically 
important, especially if you want to do 
simultaneous PC/console development 
(or worse yet, if you decide partially 
through your PC development to try 
porting it to a console). Many of the 
newest PC games require 24 or 32M B 



Michael Saladino is currently the lead programmer on Star Trek: Hidden Evil at Presto Studios Inc. His pre/ious work has found him 
at Volition Inc. during the development of Descent: FreeSpace and at Mobeus Designs Inc. Contact him at michaels@presto.com or 
just drop by his office for a late afternoon cocktail where hecan be found exploring improved living through crushed velvet. 
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of loaded resources, so trying to fit 
that into a console is a daunting task. 
It's comparable to trying to fit an ele- 
phant into a Volkswagen. And don't 
expect consoles ever to catch up. PCs 
and consoles both use the same mem- 
ory components and therefore on- 
board memory sizes for each are 
increasing at the same rate of approxi- 
mately four times every three years. As 
long as PCs cost many times more 
than consoles, they will always have 
more memory. 

So, you have a game that barely fits 
onto a PC, and then the producer starts 
talking about porting to a console. 
What do you do? Well, it's an old story 
in game development: A group of pro- 
grammers just start building a game 
and before they know it, they're at 
80M B of resources with no idea how 
they got there. Then they end up 
spending many man-months trying to 
shrink the game to fit on a consumer 
PC. At that stage, the idea to port the 
game to a console has to remain exact- 
ly that — an idea. You could never get 
it on a Playstation at that stage. 

It's all too easy to allow this scenario 
to occur because most game program- 
mers use systems with at least 128M B 
of memory, and many games can go 
well into their second half of develop- 
ment without anyone ever seriously 
looking at their memory footprint. 
Code, much I ike a gas, expands in vol- 
ume to fill its container. Therefore it's 
up to the responsible programmer to 
set a clear goal for the size of the code 
base, know where it's going, and make 
sure that it stays on course. The basic 
ideas about memory management that 
I will explore are ones common to con- 
soles and PCs. It's just more important 
to consider them while producing on a 
console game because the environment 
is so restrictive. Let's begin by looking 
at some useful coding techniques. 



Memory Pools 



Iost data in a computer game con- 
sists of large numbers of com- 
mon datatypes. Examples of this are 
the monsters in your world, bullets fly- 
ing around them, polygons that make 
them up, the execute buffers that ren- 
der them, and so on. You need to 
maintain listsof these data structures 
so they can be accessed quickly and 



efficiently. A good 
way to handlethis 
data is with a mem- 
ory pool manager. 
A memory pool 
manager is a piece 
of code that han- 
dles large collec- 
tions of dynamical- 
ly created data of a 
common type. 
With this layer of 
code, we can han- 
dletheallocation, 
de-allocation, and 
usage of these data 
elements. We can 
also keep track of 
important statistics 
about the data such 
as the greatest 

number of bullets that was ever in exis- 
tence at one time during an execution 
of the game. Knowing these statistics 
can be very helpful in setting maxi- 
mums that help compress your game's 
footprint onto a given system. I divide 
my memory pools into two separate 
versions. Thefirst is responsible for 
handling data types which cannot 
havea maximum number of elements 
forced onto them. However, they must 
share the common trait that they are 
always allocated and de-allocated in 
two independent stages. The second 
type of memory pool handles data 
types that havea limited number in 
existence at any given time, which 
lends itself well to a temporal caching 
system. 




Cyclic Memory Pools 



Let's consider thefirst style of mem- 
ory pool. To give you a clear idea 
of what type of data elements fall into 
the above description of this pool, it's 
any data list that is allocated element 
by element until it reaches its maxi- 
mum growth for that cycle and is then 
completely destroyed so the process 
can begin again. Many data types in 
games actually fall into this category, 
and most involve frame-specific data 
because the frame is a convenient 
cycle. Examplesof this data type 
include Direct3D execute buffers, poly- 
gons generated from 3D clipping, 
span s f or scan I i n e h i dden su rf ace 
removal, and Al transversal lists; all of 



Hungry common data types. These monsters' polygons are 
part of a cyclic memory pool. 



which happen to be tied to the frame 
cycle. You build the data fresh every 
frame, and at the end of the frame you 
dispose of all that you created. Looking 
through a game's code base will most 
likely reveal many more algorithms 
that use this type of data. 

Oneway to man age this data isto use 
a I i n ked I i st th at grows dy n am i cal I y 
along with thedata. Thisiseasy but not 
very fast. First, you must call malloc (or 
new) for every element you create. For 
some data types thiscould easily be 
thousands of times per frame. But since 
these data elements need to be truly 
dynamic, a pre-al located array will not 
work. Therefore, combining these two 
choices into a hybrid is what iscalled 
for. This is the first type of memory 
pool. 

This memory pool allocates large 
numbers of elements with asinglecall 
to malloc. As new elements are needed, 
the memory pool system hands out 
pointers to memory blocks that have 
already been allocated as part of a previ- 
ous chunk. If you run out, the memory 
pool will allocate an other large block of 
elementsfor thenext n requests for new 
elements. This keeps the number of sys- 
tem-level allocationsto a minimum. 
Th e tri ck i s mai n tai n i n g th e bal an ce 
between saving time by creating more 
elements with each real allocation and 
losing memory with allocated space that 
goes unused. Each type of data element 
will probably work best with its own 
block size, which is determined by 
exam i n i n g th e data type's usage d u ri n g 
an average game. 
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To reach this balance, you can cus- 
tomize the memory pool so that it 
grows and shrinks intelligently. For 
i n Stan ce, i f th e data type ten ds to al I o- 
cate the same number of elements 
every cycle, then there is no need to 
de-al locate the space every frame — 
just empty it and use it again. This 
results in even fewer system -level 
memory allocations. If the data type 
tends to spi ke up every few seconds, 
you can have the memory pool 
"prune" itself back to the average num- 
ber of elements per cycle, thereby using 
far less memory. 



Caching Memory Pools 

The secondary form of memory 
pools manage data elements that 
are dy n am i c an d can n ot be al I ocated 
and de-allocated in two independent 
stages. Although this describes nearly 
every type of data list, there is one 
other restriction that this pool places 
on data types. The data must be able to 
handle an arbitrary maximum of ele- 
ments to be enforced when a new ele- 
ment is requested. This memory pool is 
useful for "eye candy" — data elements 
such as bullets, explosions, and particle 
effects. Because console memory 
resources are very limited, wasting 
space on hundreds of bloody chunks is 
just not good. Therefore, a memory 
pool that keeps usage under control 
can be very helpful. Basically, this 
memory pool is a caching system. But 
many programmers only seem to use 
caches in reference to textures, when 
in fact they can be very useful 
with any number of data types. 

Let's look at an example of 
what happens in my latest game. 
Star Trek: Hidden Evil. When an 
enemy drone is destroyed by a 
Phaser blast, an explosion sprite 
is generated, a couple of smoke 
puffs are released, and a dozen 
spark particles are emitted. First, 
you don't want to allocate and 
delete every one of these ele- 
ments each timea drone is 
destroyed. Take a quick look at 
some hyperactive console games 
and you can see that hundreds 
of these eye-candy objects are 
created every second. A good 
solution to this problem is to 
create a set number of each type 



of data element, say 100 debris parti- 
cles, 30 smoke puffs, and so on, and 
then allow the memory pool to hand 
out new elements whenever they are 
needed without ever going over the set 
limit. This means that no system-level 
memory management occurs, which 
speeds up our code. We also know 
exactly how much memory each type 
of data takes up throughout the game. 

What happens when we run out of 
elements of a given type? A simple age- 
based caching system can be used to 
destroy old instances in favor of new 
ones. While this could conceivably 
degrade i mage qual ity or even game 
play, it will usually go completely 
unnoticed if you carefully balance 
resource savings vs. game-play costs. An 
old bullet that has been flying for three 
seconds and still hasn't hit anything 
(such as one flying towards the sky) is 
probably not going to be missed if it 
disappears unnaturally. Smoke puffs 
and debris particles are also not going 
to be missed if they disappear a little 
too soon, especially si nee the player is 
most likely focusing on the area where 
new particles are being generated. 



Memory Pools Integration 

The integration of these pools into 
our code base should be simple 
en ough si n ce th ey are a very gen eral 
class. For example, I wrote a cyclic 
memory pool type recently for han- 
dling dirty scan line updating in Star 
Trek: Hidden Evil. I had thousandsof 
data elements, each of which repre- 




Ensign Sovak is demonstrating cacti ing memory pools 
by destroying an enemy drone. Sparl<s are great can- 
didates for cactiing pools. 



sented a region on a scanlinethat 
needed to be refreshed. I created a 
memory pool of these data elements to 
request from when I needed them. 
Since! had multipledirty scanline 
screens working simultaneously, I 
ended up saving tens of thousandsof 
new and delete calls on peak frames. And 
by using very large chunks of a thou- 
sand data elements per pool, I had 
excellent cache locality coherency 
when walking the lists. 

The integration of the caching mem- 
ory pool might not be quite as obvious. 
All data elements that belong to these 
types of pools must derive from a com- 
mon class. This common class contains 
one item: thefield on which to base 
the caching algorithm. Earlier in the 
article, I implied that this caching 
scheme had to be based on the age of 
the object, but it can really be based on 
anything. Any heuristic that deter- 
mines which element in the pool 
should be expunged in favor of a new 
element will do. Once you have all 
data elements deriving from the base 
class, the rest of the integration is the 
same as the other memory pool . J ust 
stop allocating and deleting elements 
and instead request them from the 
appropriate memory pool system. 

Once most objects in our game are 
based on the memory pool classes, we 
can expan d th ei r usef u I n ess by tu rn i n g 
them into statistic recorders to monitor 
memory use. Pools can keep track of 
how many of a given data element 
have been allocated, how many have 
been used, measure the peaks, and 
determine the averages. All this infor- 
mation can be gathered easily by 
the memory pool system and 
easily retrieved to help reduce 
your game's memory footprint. 
This data is also very useful for 
customizi ng the actions of each 
memory pool used by your 
game. For instance, you might 
find that you are requesting sig- 
nificantly more bullets per sec- 
ond than you first guessed and 
it's causing them to expire too 
early. Therefore, you raise your 
allowance for bullets. 

An example of the real -world 
u sef u I n ess of th ese stat i sti cs can 
be seen in our memory reduction 
work on Beneath. Our memory 
footprint was much too large at 
the end of the project, so we sent 
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one of our programmers 
into the code to determine 
where we could cut. By 
breaking the memory usage 
down to the object level, we 
saw a tall spike at the data 
object "flare shards." Flare 
shards are pieces that fly off 
when a flare object 
explodes in the game. (A 
flare is shot from a flare 
gun, an object that many 
creatures use.) We discov- 
ered t h at t h e sp i ke was 
caused by the fact that mul- 
tiple creatures had flare 
guns, each flare gun had a 
pre-al I ocated cl i p of ten 
flares, and each flare had a pre-allocat- 
ed clip of twelve flare shards. The result 
was thousands of flare shards just sit- 
ting in memory waiting to be used. 

Our solution was to create a flare 
shard pool in which we all ocated a set 
number of flare shards at the beginning 
of the game. Then, whenever a new 
flare shard was needed, it requested 
one from a memory pool. If the memo- 
ry pool was full, the oldest flare shard 
was retired early and became the new 
flare shard. We ended up saving 
megabytes of data space. Something 
that small had actually gone unnoticed 
by us. 
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Memory Manager 



As any experienced programmer 
can attest, memory errors can be 
some of the most difficult bugs to track 
down. And when you consider that 
consoles are often weak in terms of 
development tools, having your own 
code to help track down memory bugs 
can be quite a time saver. This is where 
a memory manager can be useful (see 
Figure 1). Normally, programs use the 
standard malloc and free (or their C -H- 
equivalents, new and delete) when deal- 
ing with memory allocation; however, 
these functions do not help us track 
down memory leaks, prevent us from 
overwriting our memory bounds, or 
handle other common memory errors. 
So, let's look at a simple layer that we 
can wrap around new and delete in order 
to help us debug our code. 

Let's exam i n e h o w th i s I ay er will 
work. The meat of the code marks each 
memory allocation with a header and 



FIGURE 1. Ourmemory manager's block structure. 



trailer containing very specific data 
th at al I ows us to track th e bl ocks. I n 
the header we place a pointer to the 
source code file-name string that the 
block was all ocated in and theline 
number it was allocated on. This lets us 
identify memory errors by generating 
useful debugging messages that lead 
the programmer straight to the prob- 
lem. We also include a marker in both 
th e h eader an d trai I er th at al I ows us to 
track its current state and watch for 
boundary overwrites. 

When an allocation occurs, our cus- 
tom routine allocates memory using a 
malloc call with enough additional space 
to hold the header and trailer. The data 
portion of the block is cleared out to an 
uninitialized value. The header and 
trailer are initialized correctly with the 
filename, line number, and overwrite 
markers. This memory block is then 
put into a hash table to give us better 
searching performance when we need 
to find blocks in later stages, such as 
validation or freeing. The memory 
block is then returned with the appro- 
priate adjustment for the header and 
the rest of the program isnonethe 
w i ser t h at t h i s h as taken p I ace beh i n d 
the scenes. 

Let's look at what happens when we 
free memory. First, check to see if the 
memory block has already been freed 
by looking at its header state. Also 
check the header and trailer markers to 
see if an unrecognized value has been 
placed there, implying that a boundary 
overwrite has occurred. This does not 
catch all memory overwrites because 
obviously the overwrite could have 
written our marker, and it would 
appear untouched. However, in all my 



years of using memory man- 
agers such as th i s, I 've n ever 
seen that happen. If this 
memory block passes these 
initial tests, wemakesure 
that the block is in our hash 
table. If we find it, then we 
have a legitimate free on a 
legitimate block. Wefreethe 
data block by marking it as 
freed in its header state and 
then filling the block with a 
"freed value." The memory 
block is then removed from 
our hash table and we finally 
call freeO to actually free the 
block on a system level. 
Using these two functions, 
we can catch many memory errors 
when they are first introduced and not 
weeks later when we're trying to track 
down some very obscure, difficult-to- 
reproduce bug. We can also use these 
functions to track our total memory 
allocation, peak memory allocation, 
average memory allocation, and other 
useful code statistics. 

Finding memory leaks is another big 
advantage to this code layer. At the 
end of your program, you can call the 
FindMemoryLeaksO function tO find all 
memory leaks. The code to handle this 
isquite simple. By thetimeyou call 
thisfunction, a free should have been 
called for every malloc you made; there- 
fore, any memory blocks that still exist 
in the hash table are memory leaks. 
Just walk the table, printing out every 
block alongwith its file name and line 
number information. You now have a 
printed list of every memory leak in 
your game. 

With this layer written, how do we 
integrate this system into our code 
base? We could overload new and delete, 
or we could replace all our standard C 
memory calls with our own personal 
functions if we didn't want to use C-H-. 
The path I usually take is to use 
defines, such as this: 
#ifdef .DEBUG 
ttdefine Allocate(x) \ 

MemoryManager->Allocate(__FILE__ , __LINE__ , x) 
#define Deallocate(x) \ 

MemoryManager->Deallocate(x) 
#else 

#define Allocate(x) malloc (x) 
#define Deallocate(x) free(x) 
#endif 

This method keeps you from having 
to typethefileand line parameters for 
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every allocate function call. Also 
notice that the entire memory 
manager layer is skipped when 
not in a debug build, thereby 
speeding up thecode base in the 
final release build. (And by that 
time, all the memory bugs should 
begone, right?) 



Resource Wrapping 

The memory manager that we p 
just looked at should save 
time when tracking down memo- 
ry bugs. But what is the code real- 
ly all about? It isjust wrapper 
code; a custom high-level library 
that encloses a low-level library, such 
as the C memory manager, which pro- 
vides improved functionality. By mak- 
ing sure that our wrapper istheonly 
entry into the system, we can receive 
customized records that the low-level 
system was never designed to give. 

Let's take this idea of the wrapper 
even further. There are many other 
resources that we can surround with 
wrappers. Why not wrap thefilelO sys- 
tem? Or write a custom library instead 
of using fopenO and fclose()?This layer 
can be used to abstract packed files 
(many files merged into one for faster 
disk access) or keep endian switching 
straight between Macs, PCs, and con- 
soles. You can also use it to track down 
unclosed files that can cause quite a bit 
of trouble, as a recent incident at Presto 
showed us. 

Windows gives each application a 
maximum number of file handles, 
which when used up, can no longer be 
opened using standard C file access 
conventions. If you're opening files 
without closing them, you eventually 
useup thesefile handles and run out. A 
recent bug in our load/ save system on 
Star Trek ended up being a section of 
code that was not closing its files, and 
after five or six mission loads, we 
would run out of handles. We wasted a 
considerable amount of time on a bug 
that could have easily been avoided 
with a wrapper library reporting 
unclosed files. That's what wrapping 
systems are al I about — adding more 
functionality to already- written 
systems. 

Another benefit of writing wrapper 
code is that it helps us achieve our 
overall goal: porting between multiple 




Jack confronts his arachnophobia to squash bugs. Of 
course, our memory manager can do that for him. 



platforms. By maintaining a custom 
application interface to a system, you 
avoid having to rewrite code through- 
out a project, and instead updateonly 
one library. For instance, if you had a 
game that used Windows-specific timer 
devices, you would have to track down 
all instances of such timer devices 
throughout your code base when port- 
ing to a console. Instead, write a wrap- 
per class around the device that's used 
by the entire code base. Then, when 
it's ti me to port your game to another 
platform, you only have to touch one 
file by rewriting thetimer wrapper. All 
other code in the game remains the 
same because it al I uses your custom 
timer interface. 



Specific Porting Issues 

Let's take a moment to th i n k about 
some specific issues when porting 
from a PC to a console. First, when 
developing for a console (especially a 
new console for which the develop- 
ment environments are not mature), 
you're often developing with DOS 
prompt linkers and no support pro- 
grams outside a basic C compiler. 
So when doing a port, take advantage 
of the PC's enormous library of devel- 
opment support before actually mov- 
ing th e code to th e n ew p I atf o rm . 
For instance, using NuMega's Bounds- 
Checker is good place to start. For 
those who have never used it, 
BoundsChecker helps programmers 
find memory bugs similar to those dis- 
cussed above, such as double frees, 
overwriting boundaries, and memory 
leaks. This program can help you 



remove memory errors before 
you even move the code base 
over to the console. 

Another issue to think about is 
the difference between the 
Windows operating system and 
whatever operating system exists 
on theconsoleyou are porting 
to. (Or lack of operating system, 
as the case may be.) Windows is 
significantly more complex than 
anything you'll find on a con- 
sole. (With the obvious excep- 
tion of the Sega Dream cast, 
which has WindowsCE, but 
even that is a very stripped-down 
version of what you use every 
day on a PC.) As with all 
advanced operating systems, Windows 
can be quite forgiving of mistakes — 
sometimes too forgiving. Because if 
you make a mi stake that Windows can 
survive, chances are your console 
won't. For instance, I've seen program- 
mers not clean up after their memory 
allocation because they know that 
when they shut down their program, 
Windows will clean up their memory 
space. This is a horrible habit to get 
into, but from my experience, it seems 
common. Always work off the assump- 
tion that you do not have a safety net. 
When you type a new, match it with a 
delete immediately. When you open a 
file, make sure that you close it. 

Other issues to consider, which I do 
not have the space to get into here, are 
problems associated with other 
resources, such as video space. J ust as 
PCs will always have more main mem- 
ory than consoles, they will also 
always have more video memory, 
because PCs owners are wi 1 1 i ng to 
spend more. The same problem exists 
for sound memory. Consoles don't yet 
have hard drives for high-speed data 
spooling or massive state saves, and 
the CD-ROMs they do have are usually 
considerably slower than what is com- 
mon on PCs. In short, consoles are 
amazingly limited compared to PCs. 
But if you know what you're doing, 
you can make a game that's just as 
incredible as anything on a PC — 
sometimes even more so. ■ 

Code for the memory pool system 
and memory management wrapper 
can be found on the Game Developer 
web site, http://www.gdmag.com. 
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his isthestory of a young and inexperienced 



company that was given the chance to develop 



the sequel to one of the top ten games of all time. The 



sequel was allotted roughly one year of development with 



its full team. To makeup for the short development cycle 



and correspondingly small budget, the project was sup- 



posed to reuse technology. Not technology in the sense of a stand-alone 
engine from another game, but individual components that were spun 
off from yet another game, Thief: The Dark Project. The Thief technol- 
ogy was still under development and months away from completion 
when our team started working with it. To cap everything off, the pro- 
ject was a collaborative effort between two companies based on a con- 
tract that only loosely defined the responsibilities of each organization. 



Jonathan C hey was the project manager and a programmer on System Shock 2. Heisalsooneof the co- 
founders of Irrational Games. Prior to founding Irrational Games, he worked at Looking Glass Studios and 
prior to that he received his Ph.D. in Cognitive Science from Boston University. He is currently working on 
histan back in his hometown of Sydney, Australia. Hecan bereachedatjon@irrational-games.com. 
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Add to these gloomy initial conditions 
the fact that the game from which our 
shared technology was derived slipped more 
than six monthsfrom the initially estimated 
date, that several developers quit during the 
project, that wedidn't bring thefull team 
up to strength until six monthsfrom the 
final ship date, and that we struggled with 
financial and business problems during the 
entire project. Having learned this, you 
might anticipate the worst. Strangely, 
System Shock 2 shipped within two months 
of its targeted date and will, I hope, be rec- 
ognized as a sequel worthy of its esteemed 
ancestor. 

Let's step back and trace the origins of the 
companies and the project. Looking Glass 
Stud i OS i s f am i I i ar to man y as th e creato r of a 
series of highly innovative titles including 
the original System Shock, the Ultima 
Underworld series, the Flight Unlimited 
line and Terra Nova, among others. Three 
years ago. Ken Levine, Rob Fermierand I 
were developers at Looking Glass, struggling 
with the aftermath of Voyager, an aborted 
Star Trek: Voyager- licensed project. At the time. Looking Glass 
was in financial and creativedisarray after a series of titles 
that, though critically acclaimed, had failed to meet sales 
expectations, the latest being Terra Nova and British Open 
Championship Golf. Frustration with the 18 months wasted 
on Voyager and a certain amount of hubris prompted three 
of us to strikeout on our own to test our game design and 
management ideas. We wanted to nail down a rigorous and 
technologically feasibledesign, focus on game play, and force 
ourselves to make decisions rather than allow ourselves to 
stagnate in indecision. We wanted to run a project. 

So we formed Irrational Games. After some misadventures 
with other development contracts, we unexpectedly found 
ourselves back at work with Looking Glass as a company 
rather than as employees. Initially, our brief was to prepare a 
prototype based on thestill-in-development Thief technology 
recast as a science-fiction game. The scope of the project was 
very wide, but we quickly decided to follow in the footsteps of 
the original System Shock. Our initial design problem was 
how to construct such a game without the luxury of the actu- 
al System Shock license, since no publisher had yet been 
signed. 

Our initial prototype was developed bythethreeof us 
working with a series of contract artists. Our focus was on 
the core game-play elements: an object-rich world contain- 
ing lots of interactive items, a story conveyed through 
recorded logs (not interaction with living NPCs), and game 
play realized through simple, reusable elements. Thisfocus 
enticed Electronic Arts into signing on as our publisher early 
in 1998 — a fantastic break for us. It meant we could now 
utilize the real System Shock name and characters. 

Immediately, we went back to our original design, threw 
away some of the crazier ideas that had been percolating and 
began integrating more of the rich System Shock universe 
into the title. That was the point at which the real develop- 
ment began. 




The team at Irrational Games, from left to right: First row: Steve Kimura/Artist, 
Jonathan Chey /Project Director, Justin Wal<s/Multiplayer Programmer, 
Mauricio Tejerina/Artist, Rob "Xemu" Fermier/Lead Programmer, Dorian 
Hart/Designer, Lulu Lamer/QA Lead. Second row: Ian Vogel/Level Designer, 
Scott Blinn/Level Designer, Michael Swiderek/Artist, Rob Caminos/Motion 
Editor, Nate Wells/Artist. Third row: Mike Ryan/Level Designer, Ken 
Levine/Lead Designer, Mathias Boynton/Level Designer. Not shown: Gareth 
Hinds/Lead Artist. 



It's the Engine, Stupid 



I othing impacted the development of System Shock as 
I much as theexisting technology wegot from Looking 
Glass. Thisfact cannot be classified monolithically under the 
heading of "what went wrong" or "what went right," how- 
ever, because it went both wrong and right. The technology 
we used was the so-called "Dark Engine," which was essen- 
tially technology developed as a result of Looking Glass's 
Thief: The Dark Project (for more about its development. 
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see " Looki n g G I ass's Th i ef: Th e Dark 
Project," Postmortem, July 1999). 

The Thief technology was developed 
with an eye toward reuse, and I will 
refer to it in this article as an "engine." 
However, it is not an engine in the 
same sense as Quake's, Unreal's, and 
LithTech. The Dark Engine was never 
delivered to the System Shock team as 
a finished piece of code, nor were 
we ever presented with a final set 
of API s that the engi ne was to 
implement. Instead, we worked 
with the same code base as the 
Thief team for most of the project 
(excluding a brief window of time 
when we made a copy of the 
sou rce code wh i I e th e Th i ef team 
prepared to ship the game). 
Remarkably, it is still possible to 
compile a hybrid executable out of this 
tree that can play both Thief and 
System Shock 2 based on a variable in a 
configuration file. 

Th i s i n ti mate sh ari n g of code both 
helped and hurt us. We had direct 
access to the ongoing bug-fixes and 
engine enhancements flowing from the 
Thief team. It exposed us to bugs that 
theTHiEF team introduced, but it also 
gave us the ability to fix bugs and add 
new features to the engine. Because we 
h ad th i s power, we were someti mes 
expected to fix engine problems our- 
selves rather than turning them over to 
Looking Glass programmers, which 
wasn't always to our benefit. At times 
we longed for a finished and frozen 
engine with an unalterable API that 
was rigidly defined and implemented 
— the perfect black box. But being able 
to tamper with the engine allowed us 
to change it to support System 
SHOCK-specific features in ways that a 
gen eral en gi n e n ever cou I d . 

What Went Right 

IThe irrational development model. 
# In our hubris after leaving 
Looking Glass, we formulated several 
informal approaches to development 
that we intended to test out on our 
projects. Most of these approaches 
proved to be successful and, I think, 
formed the basis of our ability to com- 
plete the project to our satisfaction. 

First, we designed to our technology 
rather than building technology to fit 
our design. Under this model, we first 




Concept Sketch of the Psi Reaver. 



analyzed our technological capabilities 
and then decided on a design that 
would work with it. This process is 
almost mandatory when reusing an 
engine. Sometimes it can be difficult to 
stick with this when a great design idea 
doesn't fit the technology, but we 
applied the principal pretty ruthlessly. 
And many of the times we did deviate 
we had problems. 

Another feature of our development 
philosophy is that everyone partici- 
pates in game design. Why? Because all 
three of the I rrational founders wanted 
to set the design direction of our prod- 
ucts, programmers were able to resolve 
design issues without having to stick to 
a design spec, and we strongly empha- 
sized game design skills when hiring all 
of our employees and contractors. In 
all our interviews, one of our most 
pressing questions to ourselves was 
"Does this person get games?" Failure 
to "get" them was a definite strike 
against any prospective employee. 
Ultimately, the team's passion for and 
understanding of games was a major 
contributor to the design of the final 
product. 

The final goal of our development 
process was to make decisions and hit 
deadlines. We focused on moving for- 
ward, and we didn't allow ourselves to 
be bogged down. We desperately want- 
ed to ship a game and believed that the 
discipline imposed by the rule of for- 
ward motion would ultimately pay off 
in terms of the final product quality as 



wel I as del i very date. W h i I e th ere are 
features in System Shock 2 that could 
have been better if we had not rushed 
them (the character portraits for exam- 
ple), we still firmly believe that the 
game as a whole was made better by 
our resolve to finish it on time. 

2 Use of simple, reusable game-play 
# ELEMENTS. Thefidd of compa- 
nies developing first-person shooters 
like id and Valve, among others, is 
impressive. From the outset we realized 
that we would have to work smarter, 
not harder, to make a game that could 
stand up in this market. It would be a 
futi I e attempt to create scarier mon- 
sters, bigger guns, or higher-polygon 
environments. Additionally, we real- 
ized that our design time and budget 
were very tight and that we would not 
have time to carefully hand-script com- 
plicated game-play sequences in the 
engine. Instead, in an attempt to shift 
the battlefield, we chose to focus on 
simple, reusable game-play elements. 
Thesuccessof Half-Life, which 
launched while we were in the middle 
of System Shock 2 confirmed our intu- 
itions in this respect. We simply didn't 
have the time, resources or technology 
to develop the scripted cinematic 
sequences used by Half-Life. We con- 
soled ourselves with the knowledge 
that we were not even trying to do so. 

This strategy melded very well with 
our acquisition of the System Shock 
license, astheoriginal System Shock 
had already been down this road. We 
decided to expand on elements that we 
liked in System Shock and then add 
similar new systems. Each such new 
system was evaluated rigorously in 
terms of game-play benefits, underly- 
ing technology, and design-time 
requirements. 

For example, take the ship's security 
system. Early on we decided that we 
wanted to continue the surveillance 
theme from System Shock, which we 
could leverage through out the game to 
provide lots of game play for very little 
implementation cost. We realized that 
security cameras would be trivial to 
implement using existing Al systems 
(they are just Als pruned of many of 
their normal abilities) and that once 
we had cameras that could spot and 
track the player, we would be able to 
build several game-play elements out 
of them. Cameras could summon mon- 
sters to the player, so much of the 
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game play consisted of avoiding detec- 
tion by security cameras and destroy- 
ing cameras before you were seen . 
Because cameras scan fixed arcs, the 
player can utilize timing to sneak by 
cameras, pop out and shoot them at 
the right moment, or get underneath 
them and bash them with a melee 
weapon. Once a player is spotted, mon- 
sters flood the area until the player is 
able to shut off the security system 
somehow or the system times out. This 
introduces the need to deactivate secu- 
rity systems via security computers that 
are scattered throughout the level . 

This type of system was technologi- 
cally simpleto implement and required 
minimal design effort. While not com- 
pletely formulaic, the basic procedure 
to set up a camera and security system 
could be shown to designers quickly 
using a few simple rules. From this one 
system and a couple of associated sub- 
systems, we derived a large amount of 
game play without having designers 
create and implement complicated 
scripted sequences and story elements. 
When you throw together many such 
systems (as we did), you end up with a 
lot of game play. 

5 Cooperative development. System 
# Shock 2 was truly a cooperative 
development between Irrational and 
Looking Glass. Looking Glass provided 
the engine and a lot of infrastructure 
support (such as quality assurance), 
while Irrational handled the design, 
project leadership, and the responsibil- 
ity for marshaling resources into the 
final product. Both entities 
contributed personnel to the 
development team. 
Inevitably, some friction 
arose from th i s process while 
we sorted out who was 
responsible for what. 
However, this cooperation 
was ultimately successful 
because both sides were inter- 
ested in developing a great 
product, and we were ableto 
compromise on most issues. 
(On the most mundane level. 
Irrational ended up providing 
late-night, weekend mealsfor 
its development team and for 
Looking Glass on some days 
during the week.) 

Our cooperative arrange- 
ment was founded on a con- 
tractual agreement, but we 




Concept sketches of the Cyborg 
Midwife. 



avoided falling back on this contract in 
most cases. We preferred to resolve 
issues through informal discussions. 
Conceptually, Irrational was to be 
responsible for the development of the 
product and Looking Glass was to pro- 
videA/V content and quality assurance 
services. 

During the early stages of the pro- 
ject, a deal was worked out whereby a 
small number of Looking Glass person- 
nel were subcontracted to Irrational 
when it was determined that 




Irrational's development budget could 
not cover all the System Shock 2 devel- 
opment costs, and as compensation for 
the late delivery of theTniEP technolo- 
gy. Unfortunately, these personnel 
were not always aval I able on time — a 
situation which caused us much con- 
cern. We knew that this "resource 
debt" could never really be paid off 
until Thief shipped — nothing is so dif- 
ficult as prying resources away from a 
team that is trying to ship a product 
before Christmas. It wasn't until 
December 1998 that we first began to 
see some of these promised resources. 
However, these "resources" — real peo- 
ple— had just finished up Thief and 
were total I y f ri ed f o 1 1 o w i n g t h e gru el - 
ing crunch to ship Thief. The saving 
grace and reason that this arrangement 
was ultimately successful was that 
these developers were all talented and 
experienced and already knew the 
technology. Their addition to theteam 
gave us a solid boost during thefinal 
months in our ship cycle. 

The other benefit of the cooperative 
development agreement between 
Irrational and Looking Glass was that 
our respective engine programmers 
cou I d sh are kn o wl edge. Th e abi I i ty to 
walk over and quiz engine program- 
mers about systems proved to be an 
invaluable benefit that more than com- 
pensated for the lack of a rigorously 
specified and documented engine. 
Without a formal understanding of the 
engine, we had to resolve engine issues 
in a personal and informal manner. 

This process relied on the 
personal i ties of the respon- 
sibleindividualson the 
engineteam. Thus, the 
Irrational programmers bal- 
anced their time not only 
according to the complexity 
of their tasks but also 
according to how much 
support was aval I able from 
the engine side. 

Overall, Irrational's rela- 
tionship with Looking Glass 

N was an unusually close one 
and ultimately successful as 
a result of our mutual 
respect and willingness to 
work with each other. 
Despite our partnership 
being based on a formal 
contractual arrangement, it 
was our ability to workflex- 
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ibiy above this legal level that 
enabled the development to 
proceed smoothly. 

4 Design lessons from 
# System Shock. Though 
the System Shock license was 
wonderful, there were some 
problems. The biggest was sim- 
ply thech alien ge of living up to 
the original. Fortunately, we 
had the freedom to pay homage 
to System Shock legitimately by 
reusing elements from it. 
Additionally, we had access to 
some of the original developers, 
including our own lead pro- 
grammer Rob Fermier. 

As with most sequels, we 
faced the challenge of keeping 
the good elements of the original 
game while not blindly copying them. 
We knew that most players would 
want a new story set in the same 
world, with the same basic flavor as 
the original game, yet we also wanted 
to reach out to a broader audience. We 
resolved these issues by identifying the 
key elements that made System Shock 
so good and reinterpreting those ele- 
ments using current technology. Some 
elements made it through largely 
unchanged (for example, the story- 
telling logs and e-mails, the uber vil- 
lain Shodan and her close involve- 
ment with the player throughout the 
game, and the complexity of the 
world). Other elements were reinter- 
preted (such as the look of the envi- 
ronment, player interface, and tech- 
niques for interacting with the world). 
A small number of items were simply 
cut, most notably the cyberspace 
sequences — we were fairly united in 
our opinion that thesejust didn't work 
well in theoriginal. 

Notably, as with theoriginal System 
Shock, we opted to omit interactive 
N PCs in the game. System Shock 
eschewed living N PCs because the 
technology of the day was simply inad- 
equate to support believableand enjoy- 
able interactions with them. It's been 
fouryears, and that technology isstill 
not available. So we continued the tra- 
dition of System Shock and provided 
players with background information 
using personal logs and e-mails gleaned 
from the bodies of dead NPCs. 

Perhaps our biggest deviation from 
theoriginal revolved around the play- 
er interface. It's commonly accepted 
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that System Shock's interface, while 
elegant and powerful once under- 
stood, presented a significant barrier to 
entry. Our primary goal was to simpli- 
fy this interface without dumbing it 
down. We devoted more design effort 
to this task than to any other system 
in the game, and it required many iter- 
ations before we were happy with it. 
We adopted a bi-modal interfacein 
which there are two distinct modes 
(inventory management and 
combat/expl oration) between which 
the player can toggle. This was a risky 
decision. This bi-modal model was 
mandated by our desire to keep the 
familiar and powerful mouse-look 
metaphor common to first-person 
sh ooters while retai n i n g cu rsor- based 
inventory management. How we 
switched between modes became our 
biggest design challenge. Sometimes 
these mode changes are expl icitly 
requested through a mode change key, 
and sometimes they are invoked auto- 
matically by attempting to pick up an 
object in the world. So far this system 
seems to be working well, though only 
time and user feedback will tell 
whether we really got it right. 

5 Working with a young team. The 
# System Shock team wasfright- 
eningly young and inexperienced, 
especially for such a high-profiletitle. 
M any of our team members were new 
to the industry or had only a few 
months' experience, including the 
majority of artists and all the level 
builders. Of the three principals, only 
Rob had previous experience in his role 
as lead programmer. Neither Ken, the 
lead designer, nor I, the project manag- 



er, had previously worked in 
these roles. 

I t's n ot total I y cl ear h ow 
we pulled off our project 
with our limited experience. 
Partially, it must have been 
due to our ability to bond as 
a team and share knowledge 
in our communal work envi- 
ronment ("the pit"). To a cer- 
tain extent, inexperience also 
bred enthusiasm and com- 
mitment that might not have 
been present with a more 
jaded set of developers. We 
also worked hard to transfer 
knowledge from the more 
experienced developers to 
the less seasoned individuals. 
Rob worked on an extremely compre- 
hensive set of documentation for the 
functional object tools, as well as a set 
of exercises ("object school") to be 
worked on each week. These kinds of 
efforts paid back their investment 
many times over. 

This is not to say that our progress 
was all sweetness and light. The art 
team, for example, floundered for a 
long time as we tried to integrate the 
junior artists and imbue a common art 
look in the team's psyche. We had a lot 
of very mediocre art midway through 
our project and the art team was stag- 
nating. Ultimately, management had 
little to do with the art team's success 
— they were largely able to organize 
themselves and create a solid, original 
look. 

On the management front, our inex- 
perience was apparent. We blundered 
through the early stages of develop- 
ment with scheduling and manage- 
ment issues. A large problem was our 
failure to assign specific areas of 
responsibility and authority early on. 
Bad feel i n gs arose as a resu 1 1, wh i ch 
could have been avoided if we had 
clearly delineated areas of responsibili- 
ty from the start. 



What Went Wrong 



IPooR level design process. Level 
# design is a clearly defined pro- 
fessional activity in the game industry. 
It's a profession that mixes artistic and 
technical skills in equal measure, and 
the bar is raised on both fronts every 
year. Despite our understanding from 
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the very beginning that the 
level building would bea 
problematic part of the 
System Shock development 
process, we didn't quite 
grasp how difficult and time 
consuming it would be, nor 
did we expect that it would 
eventually block the ship- 
ment of the game. 

In hindsight, our failure 
to understand the amount 
of work needed to design 

1 evel s i s repreh en si bl e gi ven 
that we had seen the same 
problems emerge on Thief, 
and that System Shock 2 lev- 
els involved substantially 
more complex object place- 
mentthan Thief. I attribute this error 
mostly to our denial of the problem — 
we had a limited budget for level 
designers and there is a long training 
time required to get designers familiar 
with the complex Dark Editor. So we 
locked ourselves into working with the 
resources we had. Since each individ- 
ual task required from the designer 
(apart from initial architectural work) 
was relatively simple, it was easy to 
believe that the sum total of work was 
also relatively small. What we over- 
looked was the fact that System Shock 

2 involves so many objects, scripts and 
parameters As such, the work load on 
level designers was excessively large. In 
addition, we made a classic beginner's 
mistake and failed to provide adequate 
time for tuning in response to play- 
testing feedback. In System Shock 2 
this was particularly important 
because the ability of the player to re- 
en ter I evel s m ean s t h at t h e d i f f i cu I ty 
of a level cannot be adjusted in isola- 
tion from the rest of the game. Often 
we had to impose global changes 
across all levels, which could be very 
expensive even when the change was 
relatively minor. 

We took a novel approach to the 
level building process by attempting to 
apply design levels using a production- 
line method. Using this metaphor, we 
attempted to divorce the different 
stages of work on the level: rough 
architecture, decorative and functional 
objects, architectural polish, and light- 
ing. It was not considered necessary for 
thesame individual to be involved in 
all stages of this production process. 
This approach had positive and nega- 




tive consequences. The advantages 
were that we could track progress on 
levels, we could "bootstrap" levels fair- 
ly quickly, and we could (in theory) 
swap individuals in and out of differ- 
en t tasks. Th e d i sad van tages are f ai r I y 
obvious, and most stem from the fact 
that the various stages of level design 
are clearly not independent (for exam- 
ple, architecture is ideally built with an 
understanding of thefunctional 
objects that are to be used in the level). 
Although I think our process was nec- 
essary in order to get the game out on 
time, it probably detracted from the 
quality of some of the levels In addi- 
tion, psychological factors, such as lack 
of ownership and training issues (stem- 
ming from unfamiliarity with levels) 
speak very strongly against transferring 
people from one task or level to anoth- 
er. Nevertheless, there were several 
benefits of our procedure — mostly the 
ability to employ particularly talented 
individualsto pinch hit on particular 
levels, and the psychological benefits 
of completing architectural work early 
in theschedule. 

Perhaps the rudest shock in our level 
building process came from our misun- 
derstanding of what part of the process 
would prove to be most difficult. 
Architectural work was actually fairly 
simple, becausewe intentionally kept 
our spaces fairly clean and did not 
attempt anything too unusual. 
However, placing and implementing 
our objects was far more complex and 
involved than we expected. One diffi- 
culty that we encountered was educat- 
ing our designers in what was expected 
from them in terms of game-play 



implementation. Most of our 
level builders had previously 
built Quake or Unreal levels 
and were not familiar with the 
style of game play that we 
were trying to build in System 
Shock 2. Partially this was 
because we were si m ply 
exploring a style of game play 
that we did not entirely under- 
stand ourselves. But it reflect- 
ed a failure on our part to 
properly educate the design- 
ers Building prototypical 
spaces, looking at past games 
and conducting more inten- 
sive discussions about game 
play will all be part of our 
future projects. 
Our other major design hurdle was 
the instability and inscrutability of 
Dromed, the Dark Engine editor. 
Dromed is a cantankerous beast and 
many man-months were spent strug- 
glingwith its idiosyncrasies. Perhaps 
our biggest problem stemmed from the 
lack of support in one crucial area — 
th e part of th e en gi n e con cern ed wi th 
tran si ati n g th e desi gn er-p I aced bru sh es 
into the basic world representation. 
Like many complex 3D engines, the 
Dark Engine suffers from troubling 
epsilon issues (data errors caused by 
rounding inaccuracies) and other 
glitches that crop up during level com- 
pilation. Because the programmer who 
implemented the basic Tenderer and 
world representation was not available 
during the majority of the System 
Shock 2 development cycle, we had to 
work around these problems. It was 
often a frustrating process when the 
fundamental cause of the problems was 
not even known. Over time we devel- 
oped a set of heuristics to avoid the 
majority of the glitches, but we were 
forced to lock down much of the level 
architecture before we wanted to in 
order to ensure stability. 

2 Motion capture difficulties. The 
# Dark Engine has a complex 
creature animation playback system 
and deformablemesh Tenderer. We 
encountered many problems with this 
piece of technology along our data 
integration path, and found quirks in 
the playback systems as well. Primarily, 
the system was hampered by the fact 
that data frequently had to be modified 
by hand, that mysterious bugs would 
appear in motions during playback 
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which had not been present in the 
source data, and that few tools were 
avai I abl e f or debuggi n g an d an a! ysi s. 
We were ill -equipped to deal with these 
kinds of problems, having devoted few 
resources to dealing with thetechnolo- 
gy problems. 

Our primary animation source was 
motion capture data. We were nervous 
about the technology from the start 
and attempted to minimize our risk by 
concentrating primarily on humanoid 
creatures with a small number of 
interesting variants such as spiders 
and floating boss monsters. In retro- 
spect, thiswasa very wise decision, as 
we had a lot of trouble even with this 
simplesetof creatures. Motion cap- 
ture technology and capture services 
were contracted from a local compa- 
ny, but unfortunately this company 
viewed its motion capture work pri- 
marily as a side business and did not 
display much interest in it. In fact, 
th ey can eel I ed th i s secto r of t h ei r 
business during our project, and we 
had to fight hard to complete the ses- 
sions that we had already scheduled 
with them. 

Our capture sessions were hampered 
by our inexperience with thetechnolo- 



gy and by thefact that wedid not plan 
properly for the sessions. We hadn't 
defined key poses, rehearsed the 
motions, or ensured that our motions 
were compatible with the technology. 
Optical capture technology, thetech- 
nology that we used, can be gl itchy 
and has difficulty with motions that 
have obscured markers, as in the death 
motions that were necessary for System 
Shock 2. Over the course of three ses- 
sions, we gradually refined our 
motions, but we spent a lot of time 
reshooting failed captures from earlier 
sessions. 

Even in the best cases, most of our 
captures exhibit strange artifacts (feet 
pointing down through the ground, 
hands improperly aligned, and so on), 
whose causes are still unknown to us. 
In future projects we will hand-ani- 
mate almost all of the data, and we will 
need to understand better what aspect 
of the conversion process introduced 
these artifacts into our final game ani- 
mations, although the irregularities 
never appeared in our raw data. 
Motion capture technology, while 
highly efficient compared to hand ani- 
mation, must be approached carefully 
to obtain good results. 



S Implementing scripted sequences. 
# Motivated by the dramatic 
scripted sequences in Half-Life, we 
attempted to introduce similar ele- 
ments into System Shock 2. In doing 
so, we brokeoneof our rules: we tried 
to step outside the bounds of our tech- 
nology. Although we attempted rela- 
tively simple sequences and ultimately 
got them working, they were time 
sinks, and the payback was relatively 
slight. For example, we scripted a hal- 
lucinatory sequence in which the play- 
er character rides through the interior 
of the all en boss-monster, known as 
the Many. This so-called "Many ride" 
was the source of i nnumerable bugs — 
the player would be thrown off the 
moving platform, manage to kill his 
projected self, bump into walls, and so 
on. Weconfirmed our intuition that 
the Dark Engine does not support com- 
plex scripted sequences well because 
thetoolset (Al, moving terrain, and 
animation) is not optimized for this 
sort of behavior. The moral is, once 
again, to work with your technology, 
not against it. 

4 Inexperience with multiplayer 
# GAME DEVELOPMENT. Early in the 
project we were asked to identify the 
major ri sks associ ated with the project. 
Our number one candidate by far was 
the multiplayer component. This was 
the only new substantial enginefea- 
tu re that was to be added and it was a 
complicated piece of work. We were 
particularly nervous about this tech- 
nology for a couple of reasons. First, it 
is usually much harder to make this 
kind of pervasive change to an existing 
piece of software than it is to build it 
in from scratch. Second, Looking Glass 
had no track record in shipping multi- 
player technology and we were not 
confident that the development was 
fully understood. 

Irrational did not want to introduce 
multiplayer support into System Shock 
2 because we considered it a tangential 
feature that did not contribute to our 
core strengths. However, marketing 
concerns dictated it, so ultimately we 
acquiesced. Our lack of enthusiasm for 
thisfeature contributed to its develop- 
mental problems because we failed to 
monitor its progress adequately or raise 
concerns when that progress fell 
behind schedule. 

Because this was thefirst multiplay- 
er product developed by Irrational or 
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Looking Glass, we did not properly 
estimate the time required for the 
multiplayer testing. We did not 
devote adequate quality assurance 
resources to this feature. Too much 
time was spent testing the multiplayer 
features over the LAN and not enough 
over the more demanding modem 
connections. 

Given the difficulties posed by the 
multiplayer technologies, the engine 
developers working on the task made 
great efforts, and their early results 
were promising. However, the early 
departure of one of the programmers, 
and the fact that he was not replaced, 
ultimately doomed any possibility of 
shipping the multiplayer technology 
with the initial SKU. Reluctantly, we 
opted for a patch that would be avail- 
able at the same time as the si ngle- 
player box reached shelves. Our coop- 
erative multiplayer game will 
undoubtedly be fun and will probably 
be enjoyed immensely by a relatively 
small number of our customers. 
However, we wonder whether our fail- 
ure to deliver a promised feature in the 
box will ultimately hurt us more than 
the absence of that feature from the 
start would have. 

5 Running a company while building 
# A GAME. As th e pri n ci pal s of th e 
company. Ken, Rob and I didn't really 
understand what it took to run a busi- 
ness and simultaneously work in that 
business. None of the Irrational 
founders started the company to be 
businessmen, and we have always 
believed that the ultimate health of the 
company depended on us all staying 
involved in the development process, 
which is, after all, what each of us 
enjoys and wants to do. Unfortunately, 
as anyone who has run a business 
knows, there is a lot more to starting 
and maintaining a company than sit- 



ting around at board meetings smoking 
cigars. From the mundane matters of 
making payroll, organizing taxes and 
expense reports to business negotia- 
tion s an d con tract d i sputes, th ere i s 
substantial overhead involved in run- 
ning even a small company such as 
Irrational. In our naivete, we did not 
factor these tasks into our schedules 
and the result was that they mostly 
became extra tasks that kept us i n the 
office late at night and on weekends. 

Asa result of our misjudgment, we 
just had to work harder. Rather than 
enduring a crunch period of a few 
months, the entire last year of the 
project was our crunch time, as we 
struggled desperately to fulfill our jobs 
as programmers, designers, and man- 
agers as well as keep the money flow- 
ing in (and out) of the company. Our 
tasks were complicated further by the 
need to rein corporate the company 
from an ^corporation to an LLC dur- 
ing thefinal two months of the pro- 
ject (a legal maneuver designed to 
allow me, an Australian national, to 
be allocated company stock). 

As well as destroying our personal 
I i ves, ou r f ai I u re to j u dge th e magn i - 
tude of our task meant that we had to 



devote I ess time than we desired to 
every aspect of our work. M y program- 
ming time was severely curtailed and I 
was abl e to spen d far I ess ti me on 
System Shock 2'sAI than I wished. 
Simultaneously, I was unable to pro- 
vide the level of direct management 
that I wanted, and I was forced to post- 
pone company financial work until the 
end of the project or hurry it through. 
The results were less than optimal all 
around. 

Ultimately, System Shock 2 turned 
out better than I ever hoped it would. 
Thefinal vindication for me was sitting 
in my office and playing the game in 
thefinal coupleof weeks of the project, 
while waiting for EA to approve our 
final build. Despite the lack of sleep, 
the near-complete breakdown of my 
nervous system and the 18 months of 
time I spent working on the project, it 
was still fun to play. I like to think that 
we have managed to capture the feel of 
theoriginal game by putting more 
game play into what initially looks like 
a fairly straightforward first-person 
shooter. It's been a great first project 
for Irrational Games and we look for- 
ward to doing even better the next 
time around. ■ 
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A Platform for New Ideas: 

Why We Need an Indie Label Now 





ast night, I went to see Kristin Hersli play at 
tlie Knitting Factory. You may not liave lieard 
of lien but the club was packed. Hersh releas- 
es hermusic on 4AD, an independent label. 



It's not owned by Sony or Time Warner 
or BM G . H ersh doesn 't get th e ki n d of 
promo that major-label artists do — 
but she has more control over what 
gets released. Hersh is probably never 
going to chart — but she makes 
enough to live quite well, and reaches 
an audience of enthusiasts. 

Tonight, I'm going down to the 
Angelika with my sweetie. It's New 
York's primary venue for independent 
films. The movies they show are 
never going to appear at your 
local Odeon or Sony theater; 
they'll be lucky to reach 
500 screens in the 
states. But there are 
enough theaters 
I ike the Angelika 
to support a 
whole market 
for indepen- 
dent films - 
films that 
will never gross as 

much as a Hollywood blockbuster, but 
reach an audience of enthusiasts and 
earn enough to let many people live 
quite well. 

At times, the music and movie 
industries look dull and played out and 
repetitive. You get the same damn for- 
mulas over and over, the same artists, 
the same directors. But that never lasts, 
and for one single reason: there's a 
venuefor independent work. Indie 



labelsand indiefilm companies experi- 
ment, at lower budgets, with the off- 
beat and original. And sometimes, they 
hit a nerve, build an audience, and ulti- 
mately rejuvenate the field. It happens 
continually in the music business, and 
it happened in film this past summer 
with TheBlair Witch 
Project. 




Uustration by Jackie Urbanovic 



Right now, the game industry looks 
dull and played out and repetitive. We 
get the same damn formulas over and 
over again. Yet another shooter. Yet 
another RTSgame. Yet another racer. 

A title as original or offbeat as Sm City 
or Balance of Power or M .U .L.E. — 
hell, or Frogger— could not get funded 
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today. Gaming needs a venuefor inde- 
pendent work. 

Last year, M iller Freeman did the 
industry a service by launching the 
Independent Games Festival. It's a place 
for "garage" developers to showcase 
product, get exposure, and maybe land 
a publisher. That's great, but it's not 
enough — because they're dealing with 
th e same pu bl i sh ers as everyon e el se: 
EA, Interplay, GT, and others of their 
ilk. The majors will fund the tried and 
true, another shooter or RTSor racer. 
They'll happily exploit low-budget new- 
bieswho develop something that fits 
into slots they know how to sell — but 
they're not going to experiment with 
something new, something offbeat, 
something that will probably fail but 
just might rejuvenate the field. 

The problem? There's no way to dis- 
tribute an independent game. Yes, with 
a little effort, you can 
land a meeting 
with the buyer 
for CompUSA or 
Electronics Bou- 
tique or Software 
Etc., but they're 
not going to buy 
your game with- 
out the high-bud- 
get graphic glitz they 
expect from the majors, six 
figures in placement bucks, and a com- 
mitment to a major marketing cam- 
paign. The typical mall software outlet 
still has only 40 facings for computer 
games, and there are at least 1,500 
entertainment titles published annually. 
Anything that doesn't fit the mold isn't 
going to get exposure. 

I n d i e fi I ms work because th ere's a sep- 
arate distribution channel parallel to the 
onefor conventional film. Indie music 
works because there are a million record 
stores that cater to a million different 
tastes and a million small clubs where 
you can play to build an audience. 
We'vegot nothing similar. We've 

continued on page 63. 
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got to build it. 

How? As recently as 1991, a typical 
computer game cost around $250,000 
to develop. Graphics and sound have 
improved a lot since then, but comput- 
er games haven't gotten any better as 
games. You don't need $1.5 million in 
development funding to develop a first- 
rate game; you can do it on a $250,000 
to $400,000 budget. You just can't get 
shelf space for a low-budget game. 

But at that level, you don't need 
100,000 unit sales. You can make 
money if you can get rid of 20,000 
copies. And how tough can that be? 
Hell, 12 years ago, I sold more than 



20,000 copiesof a wonky little paper 
game called Paranoia through a wonky 
littledistribution chain cobbled 
together out of specialty hobby game 
stores and comic shops. I doubt I had 
500 points of sale in North America. 
It can be done. 

Some people are trying; Firaxi swill 
be selling Sd Meier's Antietam ! direct 
to consumers — no retail distribution. 
Michael Berlyn is bravely struggling to 
keep the text adventure alive through 
direct sales (see http://www. cascade 
publishing.com). 

But we need more. We need a com- 
pany committed to publishing truly 



original, offbeat, cool product and 
building the channel for its distribu- 
tion — instead of shoveling the same 
old crap to the same old stores. 

Gaming needs an indie label — for 
the sake of its own health, to act as 
basic R&D for the entire field, and to 
find new gaming styles that can 
attract a large audience. Because 
development costs continue to spiral 
upward faster than unit sales and we 
have to find away to break that iron 
cycle. But most importantly, because 
I'm tired of the same old same old and 
want to play something really cool 
and new. Don't you? ■ 
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